source: doc/proposals/exceptions-pab.md@ 1955fac

# Exception Handling Changes

This proposal changes the C∀ exception handling mechanism from matching an object type to a function type.
Using functions fits with function overloading in the C∀ type system.

The following shows a resumption example.

```
exception int resumpt( int, double );           // return result, no stack unwinding
try {
        i = resumpt( 3, 3.5 );                                  // exception raise
} catch( int resumpt( int i, double d ) {       // i = 3, d = 3.5
        ... return 42;                                                  // return value to raise point
}
```

The following shows a termination example.

```
exception void termin( double );                        // void return, stack unwinding
try {
        termin( 3.5 );                                                  // exception raise
} catch( void termin( int i, double d ) {       // i = 3, d = 3.5
        ...                                                                             // fall through to lexical block
}
```

There is no explicit *raise* statement.
(See Mesa Language Manual page 135, footnote)
The compiler knows a function is an exception, so it does a search call (propagation) instead of a branch call.

An exception function is denoted by the `exception` keyword to differentiate it from a regular function.
An exception function is defined in a `catch` clause, which is a local, inline implementation of the exception function.
The catch clause must specify the exception-function name and type for matching, and arbitrary parameter names to access the raise arguments.
Data is carried from the raise call to the `catch` body via the argument/parameter mechanism, and data can be returned to the raise call via function return.
An exception function cannot be passed as a function pointer nor can a raise use a pointer to an exception function.

Overloading of the exception raise occurs among existing exception functions.

```
exception int fix( int, double );
exception double fix( int, double );
exception double fix( double );
try {
        int i = fix ( 3, 3.5 );                                 // choose best overloading
} catch( int fix( int i, double d ) ) {         // match with exact catch body
} catch( double fix( int i, double d ) ) {
} catch( double fix( double d ) ) {
}
```

Normal overload resolution occur at the raise point, where the best fit *exception* function is chosen based on arguments and left-hand side.
Matching between raise and catch is exact, as for function pointers, with the selected overload chosen at the raise point (compare mangled names dynamically)

An exception function has a *kind*: return, noreturn, or dual, denoting resumption, termination, or both.
An exception function cannot be overloaded on the exception kind.
A return exception function must return a type, a noreturn exception function must return `void`, a dual exception function must return a type.
A dual exception function is specified using the quasi-keyword `dual`.

```
exception int dual( int, double ) dual;         // Dual, return result or exit handler block,
                                                                                        // no initial stack unwinding
```

Within the handler for kind return (stack not unwound), the handler *must* return a value as for any value returning function;
any other control-flow statement or fallthrough is an error, like `break` or fallthrough on a value returning function.

```
        } catch( int fix( int i, float j ) ) {  // stack not unwound, i/j accessible, => must return
                return 42;                                                      // => return to fix call, not return of lexical function
                break;                                                          // syntax error => must return
                // fallthrough => must return
        }
```

Within the handler for kind noreturn (stack unwound), `break` or fallthrough ⇒ exit handler, like in the `case` clause of a switch statement;
any other control-flow statement works on the lexical context outside the handler.

```
        } catch( void recover( int i ) ) {              // stack unwound, cannot return
                break;                                                          // => exit catch routine
                return;                                                         // => return from lexical function
                // fallthrough => => break
        }
```

Within the handler for kind dual (stack not unwound), `break` or fallthrough ⇒ exit handler and unwind stack, or return a value to the raise at top of the stack.

```
        } catch( int dual( int i, float j ) ) { // stack not unwound, can return
                return 42;                                                      // => return to fix call, not return of nested function
                break;                                                          // => exit catch body
                // fallthrough => break
        }
```

In all cases, a handler can raise another exception.

Resumption example:

```
exception int fix( int, float );
void foo() {
        try {
                for () {
                        ... if ( ... ) x = fix( 3, 5.4 ); ...
                }
        } catch( int fix( int i, float f ) ) {
                ... return 42;                                          // fix up problem and return to raise
        }
}
```

Termination example:

```
exception void end_of_file( ifstream is );
void foo() {
        int i;
        try {
                for () {
                        sin | i;                        // internally, calls end_of_file( is ) to raise exception
                        sout | i;
                }
        } catch( end_of_file( ifstream is ) && is == sin ) { // "is" used in predicate selection
                // close file
        }
}
```

Dual example:

```
exception int dual( int i, float ) dual;
void baz() {
        try {
                for () {
                        if ( ... ) x = dual( 3, 5.4 );
                }
        } catch( int dual( int i, float f ) ) { // stack not unwound
                if ( ... ) return 42;                           // return to raise calls
                if ( ... ) break;                                       // exit catch body
                // fallthrough => break
        }
}
```


## Default Handler

An exception function can have a static body, which defines the action if the exception is not caught.
If no body is specified, there are default actions added.
This matches with `defaultResume` and `defaultTerminate` in current C∀/μC++.
Here a parameter name is necessary to access the raise argument(s).

Resumption default:

```
exception int resumpt( int i ) {                        // called if no handler found
        // return default correction or abort or raise another exception
        // default if not specified is to call UnhandledException at resumer or joiner.
}
```

Termination default:

```
exception void termin( double d ) {                     // called if no handler found
        // abort or raise another exception
        // default if not specified is to call UnhandledException at resumer or joiner.
}
```

Dual default is the same as termination default, as having a default correction action is unlikely.


## Polymorphism

A catch clause can be polymorphic using the RTTI information in a mangled name.

```
forall( T | { T ?+?( T, T ); } )
exception T foo( T t ) { return t + t; }

        try (
                i = foo( 3 );                                           // raise
        } catch( int foo( int t ) ) {                   // monomorphic handler
                return t + 3 / t;                                       // can do something
        } catch( forall( T | { T ?+?( T, T ) } ) T foo( T t ) ) { // polymorphic handler
                return t + t;                                           // cannot do much
        }

```

Matching is a pattern match on the mangled name (assuming there is enough information):

```
_X3fooQ1_0_0_5__X16_operator_assignFBD0_BD0BD0__X12_constructorFv_BD0__X12_constructorFv_BD0BD0
        __X11_destructorFv_BD0__X13_operator_addFBD0_BD0BD0__FBD0_BD0__1
```


## Separate Compilation

**test.hfa**

```
typedef struct S {
        void (*f)( int );                                               // general function pointer
} S;

void foo( int ) throws( E );                            // external
void bar( int ) throws( F );

void mary( S & s );                                                     // external
void jane( S s );
```

**test2.cfa**

```
#include "test1.hfa"
#include "stdlib.h"

void foo( int ) { printf( "foo\n" ); }
void bar( int ) { printf( "bar\n" ); }

void mary( S & s ) {
        s.f = random() % 2 ? foo : bar;                 // randomly insert a function
}

void jane( S s ) {
        s.f( 3 );                                                               // call field f
}
```

**test1.cfa**

```
#include "test1.hfa"

int main() {
        S sfoo;

        mary( sfoo );                                                   // initialize field f

        try {
                jane( sfoo );                                           // calls sfoo.f in jane
        } catch( ... ) {}                                               // cannot statically check correct handler is present
}
```


## `throws` Clause

A `throws` clause can be added to a regular function to indicate alternate outcomes.

```
int foo(...) throws( int ex( int ), float ex( int ), char ex( double, double ) );
```

The `throws` clause is *not* part of the function type, and hence, is *not* used for overloading.
Functions with a `throws` clause are handled by a separate type-checking pass, which examines the static call-structure to determine if calls are nested directly or indirectly within guarded blocks with matching catch clauses, e.g.:

```
int bar( int i ) throws( int fixup( int ) ); // might call fixup directly or indirectly

void foo(...) {
        ... i = bar( 3 ); ...                   // call statically nested within handler for fixup in baz
}
void baz() {
        try {
                foo(...);
        } catch( int fixup( int ) ) {                   // handler for bar
                ... return 42;
        }
}
```

If this type check fails because of separate compilation, e.g., `baz` is in a different translation unit, a warning is given, and a dynamic check is wrapped around the call to `bar` to verify only the specified exception functions are raised.
This dual approach allows all forms of reuse to exist, and is similar to checked/unchecked exceptions in Java.


## Polymorphism Extension

A new kind of polymorphic parameter is introduced, `throws`, listing the possible empty set of exceptions (alternate outcomes) that can be raised exception, but a possibly empty set of exceptions.
A set of exceptions can be used in an exception signature in the same way a single exception can be and are traced from callee to caller in the same way a single exception is.
They do not interact with throws or catches as those work on concrete types.
At the top and bottom of the polymorphic call stack concrete functions throw and catch the exception, passing through the polymorphic section. 

```
forall( T, [N], throws E )
        void apply( void op(T &) throws(E), array(T, N) & data ) throws(E) {
                for ( i; N ) op( data[i] );
}
```
Given the concrete usage:

```
void op( int ) throws( void WWW( int ), Y, Z ) { ... }
array( int, 10 ) arr;
try {
         apply( op, arr ); // op(... ) => if (... ) WWW(...)
} catch( void WWW( int ) ) { ... // apply can raise from op
} catch( exception Y ) { ... // apply can raise from op
} catch( exception Z ) { ... // apply can raise from op
}
```

The call to `apply` composes a list of all potential exceptions thrown by arguments.

Imagine we passed around a set description (a list of type identities for each exception in the set) and at the edges of the polymorphic space we check for an unknown exception type against these sets.
The static checks should ensure that every exception falls into one set;
in fact if there is only one knows set we know it must belong to it.
Then we wrap it up with a little marker saying which set it is part of and which one in the set it is.
That gets passed through as an opaque exception until we return to monomorphic code, then it is unpacked and passed normally.


## More Examples

```
enum FloatExceptions ! { Invalid, ZeroDiv, Overflow, Underflow, Inexact };
exception double arithmetic( double op1, double op2, int retcode ) {
        // default abort
}
enum IntExceptions ! { ZeroDiv, Overflow, Underflow };
exception double arithmetic( int op1, int op2, int retcode ) {
        // default abort
}

void foo() {
        double x = 3.5;
        try {
                x = x / 0.0;
        } catch( double arithmetic( double op1, double op2, int retcode ) ) {
                if ( retcode == FloatExceptions.ZeroDiv ) ...   // analyze retcode
        }

        int i = 3;
        try {
                i = i / 0;
        } catch( double arithmetic( int op1, int op2, int retcode ) ) {
                if ( retcode == IntExceptions.ZeroDiv ) ...             // analyze retcode
        }
}
```