Programmers can use exception processing to handle cases that interrupt the main flow of control. The advantage of exception processing is that special cases for exceptions do not need to be explicitly coded in the main program flow. This greatly simplifies programs as exception processing can account for much of the code in a program. While there is one main path for a transaction there may be many exception conditions that need to be accounted for.

An exception can be triggered by an Assert command, by an exception condition detected by the processor (e.g. divide by zero), by an implied language specific check (e.g. array bounds), or by a run-time error. An exception handler is a procedure that is reached when certain exception conditions occur. They are placed after the primary procedure in a file.

In the course of writing a program it is often not possible for programmers to anticipate exception conditions in advance. Also additional exception conditions need to be accounted for when code is changed. Separating exception processing from mainstream processing allows exception conditions to be added without making significant changes to the main body of the program. This goes along with the tendency to first write main line code and then add exception cases later.

assert  [] [({pass | fault}  ) | (catch  Label)]  []

You can display the comment on an Assertion command when the assertion condition is not met. Assertions without comments use the message, "ERROR: Generic error." Exceptions detected by the processor have canned messages that are machine dependent. Checks generated by the compiler and run-time Fault exceptions also have canned messages.

In the simplest form of exception processing, an exception is triggered and its corresponding message is written to the standard output and the program exits. All you need to do to write programs like this and then add commented assertions to the code as needed.

Ideally exceptions are never triggered when a program runs. Even then unanticipated circumstances can arise that raise an exception. Assertions are also very helpful when coding as they can detect programming errors early. Preconditions are included in procedure signatures and help programmers write calls to them. In any project it is helpful to establish a policy on exception processing early on.

When an exception occurs the run-time system calls the first chance handler, Gilda_Run$First_Handler, upon entry. The last chance handler, Gilda_Run$Last_Handler, is called upon exit if the exception unwinds out of the program or thread. Their signatures are in the Gilda_Run Class.

The version of the first chance handler in the run time system does nothing on Error exceptions. On Faults it calls the last chance handler and terminates the program or thread. The last chance handler prints the corresponding message to the standard error stream. This ensures that any exception that is not caught will notify the user.

When you import the Gilda.Basis library first and last chance handlers in the Assertion class are used. The first chance handler sets up the Global Assertion variable and the last handler prints a more elaborate message.

You can override these by coding your own custom versions. Use the signatures in the Gilda_Run Class to write the procedures. In the body of your project Class list them using their qualified name. You'll also need to declare a dependency so that they get compiled.

* => First_Handler  Last_Handler

gilda  Gilda_Run$First_Handler
gilda  Gilda_Run$Last_Handler

The system handlers are useful for reporting messages in a termination model of exceptions. Here is the flow of control for a terminating exception.

method ROOT
   |
   V
method A
   |
   V
method B
assert  <Condition>  -->  Gilda_Manager  -->  Print Comment  -->  Exit

If you want the program to resume rather than terminate after an exception occurs you can specify a handler to catch the exception. When an exception occurs each method in the call chain is unwound up to the procedure that catches the exception. When a method is unwound its local variables are drained; as with a normal return.

A simple recoverable exception mechanism can be written by designating a general handler high up in the call chain. It catches exceptions, reports the error, and returns so that the system can restart.

     Flow of control for a general exception catcher:

method ROOT
    |
    v
method A                              A resumes by calling B again
    |                                           ^       
    v                                           |     
method B (with handler)   B catches, resets, returns
    |                         ^
    v                         |
method C                  unwind C
    :                         ^
    :                         |
assert  <condition>  -->  Gilda_Manager

A Handler can also be specified to run when exceptions are caught. After a Method catches an exception and is drained the Handler is called instead of recalling the Method. When the Handler returns it returns to the caller of the Method. The following Class declaration specifies a Handler for a Method.

class <Class>
   :
<Language>  <Method>  catch  <Handler>
<Language>  <Handler>
   :
return

A system build dependency is established so that Handler is included in the build whenever Method is.

The Handler must have the same parameter declarations as the Method that catches the exception. The Handler can pass back data in any Change or Exit parameters before it returns. The Handler also needs to be declared in a class with it's own language declaration. When a Handler is used as a Catch operand it will be included in the build. No dependency declaration is needed.

     Flow of control for a general exception handler:

method ROOT
    |
    v                     unwind A; Call A's Handler with A's parameters.
method A (catcher)            ^     A's Handler returns to ROOT.
    |                         |
    v                     unwind B
method B                      ^
    |                         |
    v                     unwind C
method C                      ^
    :                         |
assert    -->  Gilda_Run.Trap  -->  (Comment)  -->  stderr

When a program or library is built any messages in Assertion commands are written to a file. That file along with other intermediate files used in compilation are created in the asm/ directory under your main project file. Their names consist of the project name and a suffix.

<project>.iex  -  Assertion messages
<project>.icl  -  Classes included in the build
<project>.ipr  -  Procedures included in the build  

This exception handling mechanism provides these benefits over status error codes and the try-throw-catch exception model.

• Exception processing is decoupled from the application body of a program. This reduces the complexity of main line code.


• Performance is not degraded. There is no additional overhead for exception processing. Using assertions and exceptions to detect abnormal conditions genrates fewer branches than explicitly coding checks in the main body of a program.


• Supports code reuse. Different implementations of a reusible class can be plugged in without changing the exception processing or testing. A reusible class can have many assertions and only those that apply will be used depending on the context.


• Assertion checking makes code more robust. Assertions can be used without imposing performance penalties for those that aren't needed in the production system. This helps when debugging or writing reusible classes.


• Context data is used to process exceptions. Exceptions are not named as they introduce global dependencies. Named exceptions act like an interprocedural Goto command. In large programs there are way too many possible exception cases to name. As programs scale up the impact of changes on named exceptions becomes unmanagable.