Exception Processing

NetKernel processing associated with DPML may result in errors. There are three categories of errors:

1. A DPML program may have a syntactic error and will not compile.
2. A DPML instr may have an argument or target that is not available.
3. During the execution of an instruction an accessor or service may thrown an exception.

The first category of problem will cause the DPML runtime to thrown an exception and the logic in the program will have no opportunity to handle the error. This extrinsic exception can be captured and handled by the code that invokes the DPML runtime.

The second and third categories of error are runtime exceptions and are available to the DPML program which may handle them and act accordingly.

In DPML exceptions are captured by the block <exception>. Exception handling blocks can be placed in a DPML program anywhere an instr is valid. The <exception> element may contain instructions, sub-sequences and extended exception handling just like a regular <seq> element.

The first exception block within a parent element that contains the instruction that generated the exception will catch an exception. If no exception block exists within that parent element then an exception block is sought within the parent element's parent. This processing of searching for an exception block continues all the way to the root of the DPML program (the root idoc element) at which point the exception is considered unhandled and is thrown by the DPML runtime as an exception to the initiating requestor.

Inside an exception handling block the DPML program has access to the exception that was thrown by using the URI identifier this:exception.

Exceptions can be deliberately thrown using the throw instruction.

The following DPML program shows an example of throwing a deliberate exception, catching it and using the exception: