The Four Different Roles That Exceptions Play

We argue that exceptions are used in four significantly different ways. On this page we summarise these four roles:

Alternative Return.

An alternative-return is exactly what it says, namely a return from a function that in some sense is not standard. It typically represents a variant use-case. The important things to note are that it represents a perfectly normal situation (i.e. nothing is "in error") and that, unlike an exception, it does not propagate but immediately promote.

  • When implemented by exceptions, the try-catch-continue block is the Alternative Handler.
  • When not handled immediately, an Alternative Return becomes an Unhandled-Alternative Rollback.
  • Alternative Returns can only be raised explicitly.

Rollback

This corresponds to what we commonly think of as an exception. Rollbacks are required to propagate back up the calling stack, reversing any state changes until they meet the dynamic transaction handler. If there is no handler then the rollback promotes to a failover.

In current programming languages it is frequently very difficult to identify all the state that needs to be reversed. We regard this as a common programming mistake.

  • The try-catch-continue block is the Transaction Handler.
  • The using/try-catch-rethrow/try-finally blocks are the Repair Handlers and are associated with one or more Transaction Handlers.
  • If not handled, a Rollback becomes an Unhandled-Rollback Failover.

Failover

These are not especially widely used, as most programming language runtimes do not support the notion of supervising threads/processes/coroutines. However, our general application framework is a set of cooperating virtual machines and in that context a failover is the managed failure of a virtual machine.

These are characterised by the disposal of all the state associated with a virtual machine (or thread). If anything untowards happens during a failover it is promoted to a panic.

  • The code associated with closing down the existing work and resetting the environment (or virtual machine) is called the Failover Handler or Supervisor.
  • The attempt to handle a Failover may succeed in which case it is a Handled Failover.
  • If not handled, a Failover becomes an Unhandled-Failover Panic.
  • If this is caused by an explicit Panic within the Supervisor code, this is a Planned Panic.
  • If this has any other cause, this is an Unplanned Panic.

Panic

These are common in everyday programming and correspond to an untrappable exit from the application.

  • A panic is handled by the host Operating System.
  • Explicitly invoked panics are planned. Others are unplanned.