Exception Handling

From dis-Emi-A

Contents 1 Intro 2 Simplicity 3 Possible Syntax 4 Old Examples

Intro

There are basically two types of exceptions which can happen, and it depends on the source of the exception.

Faults

Faults are exceptions which occur due to an abnormal operating condition. Faults are in general be temporary, and the cause is not directly controllable by the calling program. In normal operations a program may be able to simply try again and have it work.

Errors

Errors are exceptiosn resulting from the provision of incorrect arguments, or a defect in logic or calculation. Errors are in general permanent, indicating that attempting the same operation with the same parameters will fail in all subsequent calls.

Simplicity

It generally needs to be very easy to handle both types of exceptions -- it is the crux of most existing languages that dealing with exceptions is tediuos or burdonsome, thus they are usually handled incorrectly. The two major types of bad programming resulting from this are the ignored exception

catch( Exception ex ) 
{ }

and the incorrect use of types, in particular a null/nil value rather than a proper exception:

Object obj = map.getObject( key );
if( obj != null ) { }

The last one both misuses a type and falls into the Evil If trap.

The simplicity must then be that exceptions are firmly embedded in the language -- and in such a way that the most common patterns can be transformed into efficient code by a compiler.

Possible Syntax

It looks possible that we could simply use the Branching syntax combined with the Continuation syntax.

Simple Example:

Object obj = map.GetObject;
  => [ except is NotFound ] obj = defaultObj;

Longer Example:

 { 
   Object obj = map.GetObject();
   Send( obj );
 }
 => [ except is NotFound ] 
   Warn( "No object sent" );
 => [ except is IOError ]
   Warn( "Failed to send the object" );
 => 
 {
    //a finally block
    Notice( "Sending completed" );
 }

By these examples the variable except is just a special variable which refers to the exception of the current expression/block. The remaining handling syntax is completely generic.

Old Examples

Firstly, we need to do away with "try" and assume every block can handle exceptions. Perhaps

 {
    Object obj = map.GetObject();
    Send( obj );
 }
 except( NotFound )
 {
    Send( obj.Default );
 }

This of course still leaves the problem of the except notation, since it requires a keyword and a classname, and due to conflicts the names will of course be longer than simply NotFound.

Perhaps this can be integrated into the general if replacement, where each item simlpy has a branching pattern, this time one after the block:

{ 
  Object obj = map.getObject();
  Send( obj );
}
[ Exept.NotFound ]
{
   Send( obj.Default );
}

Hmm, it needs to not conflict with the Branching section, though clearly it is a branch.

 { 
    Object obj = map.GetObject();
    Send( obj );
 }
 
 @ Except.NotFound
 {
 }

 @
 {
   //a finally block...
 }

Let's try using the brancing notation again, in a simpler case.

Object obj = map.getObject();
 ! [ except : NotFound ] return;

Longer form:

{ 
   Object obj = map.GetObject();
   Send( obj );
}
! [ except : NotFound ] 
{
   Warn( "Not found/sent" );
}
! [ except : IOFault ]
{
   Warn( "Could not be sent" );
}