Assertions raise an exception when a condition is not met. From there you can handle the exception according to whichever strategy you want. Most commonly a message is logged or reported to the end user and the program will then either terminate or recover.

Liberal use of assertions is a great way to help bulletproof code by implementing internal consistency checks. During software development assertions can detect errors early and provide hints that make debugging easier. If an exception was to unexpectedly occur in a production system, it could log the failing conditions and reset itself or safely shut down.

The simplest strategy is to avoid exceptions all together. In this approach if an exception was to occur it would be considered a progamming error. Alternatively you could report an error and terminate the program. If you code assertions with no handlers in your program a default handler will print the comment on the assertion and exit the program.

assert  Condition  pass Context;      Exception message

Should the Condition fail the Context expression is evaluated and saved as a string by the Run Time System. The comment on the assertion is also saved as a constant string and can be used as a default message. Additionally the method containing the assertion and its line number are saved.

The sample phonecode program illustrates the default mechanism in action. When you run it with an invalid input file you'll see output like:

line 5 )  ERROR:  A code word does not begin with a letter.

Exceptions come in two flavors, faults and managed exceptions. Fault conditions result from programming errors, corrupted systems, or problems with resources used by the program. Faults are not part of the buisness logic and are generally not expected under normal operation. An assertion can designate a fault by using the "fault" keyword.

assert  Condition  fault Context;     Exception message

Faults can occur in any procedure despite the programmer's best intentions. Consequently a fault can be raised even in functions and Pure or Safe methods. To support this concept, faults are handled separately from other managed exceptions and the two kinds can use different strategies. Any exception not explicitly designated as a fault is a managed exeption. When faults are separated out, far fewer exceptions remain to be managed; reducing the amount of exception processing needed.