This shorter document discusses exception handling as a topic unto itself. Its final section introduces action expression syntax and semantics as an extension to the Objective-C programming environment.

Exception handling

The absence of a way of handling exceptions explicitly, independently from normal processing, is a severe obstacle to software quality and reusability. Since subroutines routines return the same way, regardless of whether they succeed or fail, a method that should return a handle to a new object might instead return an error code to indicate that it could not, perhaps because of insufficient memory. Since any such call might fail, the caller must check every return value, reporting any failures to higher levels with similar means. This is sufficiently tedious that it is neglected, allowing unhandled exceptions to crash the application.

An `exception' is a situation where a computation does not proceed as planned, perhaps because of I/O errors, inability to allocate a new object because of insufficient memory, or defects in the software itself. `Exception handling' is a language/environmental feature that reserves the normal subroutine/message return channel exclusively for normal processing. Routines that return normally can be assumed to have succeeded, since those that fail will return via an independent channel reserved for exceptions. Low-level routines never fail by returning an error code for the caller to decipher, but by `raising an exception'. Higher level routines establish code fragments, `exception handlers', that will receive control if the exception they are to handle is raised by a lower-level routine.

The following shows how exception handling might be done in C, in order to show the limitations of this solution and how these limitations are addressed in TaskMaster. TRY() is a C macro that uses setjmp() to record the machine's register settings before entering the computation that might fail; the foo subroutine.

main() {
        TRY() {
                int v = foo();
                ...normal processing...
        } HANDLE(OUTOFMEMORYEXCEPTION) {
                ...handle low memory exceptions...
        } HANDLE(IOEXCEPTION) {
                ...handle IO failure exceptions...
        } OTHERWISE() {
                ...handle any other exceptions...
        }
}
foo() {
        TRY() {
                int v = bar();
                ...normal processing...
        } HANDLE(OUTOFMEMORYEXCEPTION);
}
bar() {
        id newObject = [SomeClass new];
        ...normal processing...
}

The problems with this scheme will be familiar to anyone who has used it extensively. Since the exception handlers unconditionally execute in the context of the calling routine, as opposed to as a subroutine of the routine that detected the exception, information is unconditionally lost as to what sequence of calls triggered the exception. For example, foo's OUTOFMEMORYEXCEPTION handler can determine that bar, or one of its subroutines, failed because of insufficient memory. But it cannot tell which one, because the stack has been rewound before the handler has been invoked. This makes ituseless for exception handlers to invoke process inspectors (debuggers), sincethe debugging information has been unconditionally discarded.

TaskMaster takes a different approach. It exports the handler to the exception,rather than the other way around. By invoking the exception handler as asubroutine of the exception, the stack is never erased until the user's codehas had a chance to use it. One way to think about the difference is thatTaskMaster exception handlers are first class C subroutines, not compoundstatements as in the preceding example. They are passed as function pointers[22] in the exception handler stack and invoked as subroutinesby the logic for raising an exception.

Action expressions are a compiler-supported enhancement to deal with the factthat code that uses function pointers extensively can be hard to write andnearly impossible to understand later. This extension, which is planned for afuture compiler release and is not yet available, would let this example becoded like this:

main() {
        [{ int v = foo();
                ...normal processing...
        } ifException:{
                if (OUTOFMEMORYEXCEPTION) {
                ...handle low memory exceptions...
                } else if (IOEXCEPTION) {
                ...handle IO failure exceptions...
                } else {
                ...handle any other exceptions...
                }
        }];
foo() {
        [{ int v = bar();
                ...normal processing...
        } ifException: {
                ...handle exceptions...
        }];
}
bar() {
        id newObject = [SomeClass new];
        ...normal processing...
}

* The code to be protected from exceptions, and the code for providing thatprotection, can be written alongside each other in a familiar readable fashion,without the syntactic clutter of working with function pointers directly.

* The compiler will generate the necessary boiler plate automatically,transforming the action expressions into function definitions that theunderlying C compiler knows how to handle. Although actions look syntacticallylike expressions, they are semantically analogous to function pointers that theexception handler can invoke as a subroutine of the exception, as opposed towithin the scope of the calling site.

* TaskMaster's run-time support for this style of exception handling is inplace today, and can be used by following the code generation strategy that theextended compiler will use; coding action instantiation statements by hand.

A final TaskMaster feature is that exception handling is closely integratedwith lightweight multi-tasking. Each task maintains an independent stack ofexception handlers that inherits any exception handlers of its parent task. Forexample, a parent task can provide supply handlers of last resort forexceptions in its subtasks. TaskMaster automatically initializes the root taskwith a default handler for all possible exceptions.

This handler of last resort features an interactive task inspector withinteractive debugging facilities. A programmer can use the inspector to examinethe call history that led to the exception and specify whether to exit theapplication, produce a file suitable for detailed debugging, or to continue inspite of the exception.

The inspector is based on a library of routines that interpret C call historiesin terms that a programmer can easily understand. For example, call historiesare not presented as hexadecimal numbers but in symbolic terms. Subroutine andselector names are spelled out with all arguments decoded. Object referencesare presented in terms of the object's class name and its address, stringpointers are presented in terms of the string's contents, and so forth. Thesedecoding facilities are based on a library of platform-dependent routines inthe TaskMaster PDL. These routines support such platform-dependent operationsas loading the application's symbol table. They also provide the heuristicrules that determine which format should be used in presenting the otherwiseuntyped numbers in a C call stack[24].

Apart from such convenience features, the exception handling is notparticularly dependent on the target platform. Exception handling is based on apair of routines, setjmp() and longjmp(), in the standard[25] C run time library. Nor is it particularly dependent onmulti-tasking, except that bundling exception handling with multi-tasking makesit possible for subtasks to manage exceptions independently from other tasks.Nor is exception handling specific to Objective-C. Its benefits are equallygermane to ordinary C programs. This is another reason why TaskMaster'sexception handling facilities are brought forth through two API's, amessage-based API for users who want to treat exceptions as objects and afunction-based API for those who want to treat them as functions.

Action expressions

The classical examples of a deferred computation is a computation that a collection is to perform on each of its members or that a menu is to perform when selected. As the following examples show, action expressions are generally useful, especially for defining menus, operating on collection members, handling exceptions, and defining lightweight tasks:

[ aMenu str:"Open" action:{ code to do a menu operation}];
[ { code that might fail } ifException:{ code to handle the exception } ];
[ anyCollection do:{ code to be applied to each member} ]; 
[ { code to run as a separate task } forkWith:2,arg1, arg2];

extern int aGlobal;
foo(aFormal)
        int aLocal;

        ...long, involved computation...

        /* 
         * Pass this action to bar, which may run it later 
         */
        bar({ int formalArg; | printf("...", aGlobal,aFormal, aLocal, formalArg);});

        ...long, involved computation...
}

extern aGlobal;
static dummyFv, dummyLv;
static dummyFn(formalArg) 
{
        printf("...", aGlobal, dummyFv, dummyLv, formalArg);
}
foo(aFormal) {
        int aLocal;

        ...long, involved computation...

        /* 
         * Pass dummyFn to bar as a function pointer 
         * so that bar can run it later 
         */
        dummyFv = aFormal;
        dummyLv = aLocal;
        bar(dummyFn);

        ...long involved computation...
}

static void fn(struct { int aGlobal, aFormal, aLocal; } *c, int formalArg) 
{
        printf("...", c->aGlobal, c->aFormal, c->aLocal, formalArg);
}
foo(aFormal) {
        extern int aGlobal;
        int aLocal;

        ...long, involved computation...

        bar(createAction(fn, 3, aGlobal, aFormal, aLocal));

        ...long, involved computation...

}