Exceptions and error handling

4 Exceptions and error handling

4.1 Exceptions

There are two syntactic constructs dealing with exceptions:

try e_try handle e => e_handle
Execute the expression e_try. If e is an exception literal, then if the exception e is raised and not caught during the execution of e_try, expression e_handle is evaluated. If e is not a literal exception, it is viewed as a variable name to which any exception raised during the evaluation of e_try will be bound, for an ensuing evaluation of e_handle.

Using the variable-binding form of the try...handle block allows any PLAN exception to be caught. Therefore a simple, in-packet error-reporting system may be set up. For example :
```
svc print : 'a -> unit

fun exnreport(h:host list,e:exn) =
  (print("I raised ");
   print(e);
   print(" on ");
   print(h))

svc thisHost : void -> host list
svc getRB : void -> int
svc defaultRoute : host -> host * dev

fun main(home,...) =
  try
    ...
  handle e =>
    OnRemote(|exnreport|(thisHost(),e),home,getRB(),defaultRoute)
```
raise e
Raise the exception e. Evaluate the handling expression of the tightest lexically-enclosing try...handle construct.

Note that service calls and language constructs may raise exceptions which can be caught with try...handle blocks. Language level exception provided are:

ServiceNotPresent is raised when a service call is attempted for which the service is not resident on the active node. Note that because service calls are syntactically identical to function calls, the evaluator assumes that any unbound function name in an application is a service, thus raising this exception.
DivByZero is raised upon an attempted division by zero.
Hd is raised when hd is applied to an empty list.
Tl is raised when tl is applied to an empty list.
NotEnoughRB is raised when the current packet runs out of resource bound, or if it attempts to allocate to a child packet more resource bound than it has available.
HostNotLocal is raised when a router is asked to forward a packet to a node which is not one of its link-layer connections.
NoRouteEntry is raised when the invoked routing function does not know of a route for the specified destination node.

4.2 Error handling

Any exception raised by a PLAN program can be caught by a top level try...handle block. However, in the case that an exception arises outside of packet execution (such as if the packet runs out of resource bound before it can be evaluated), or if no enclosing try...handle block is defined, the packet handler is used for recovery. This is the name of a function, stored as part of the packet, which should be invoked back on the source. This function must have the following signature:
string × host × a chunk ® unit
The arguments are, respectively, the error which occurred, the node on which it occurred, and the (truncated) chunk which was (or would be, on arrival to the evalDest) evaluating when the error occurred. These arguments have the following properties:

the error argument will either be the name of a PLAN exception, or one of the following:¹

ParseExn.UndefinedType
ParseExn.SyntaxError
ExecExn.TypeError
ExecExn.ArgMismatch
ExecExn.AppError
ExecExn.UnboundVariable
ExecExn.BadRoutFun
ExecExn.EmptySequence
ExecExn.Generic
Unix.Unix_error
Net.MarshallingException
Unknown

the chunk argument is truncated to ensure that the error can be properly sent back to the source without need for fragmentation. Specifically:
- The code field of the chunk is omitted
- The fn_to_exec field of the chunk is left as is
- The bindings to the fn_to_exec are truncated as follows:
  Values of type unit, int, char, bool, host, port, key, and dev are left as is. Values of string, exception, blob are truncated to the first 16 characters/bytes. Lists are truncated to the first element only (which is itself truncated). Tuples retain their arity while the values they contain are truncated. Finally, a chunk has its code and bindings omitted, and the fn_to_exec is truncated to at most 16 characters.

A default handler, defHandler is provided. There also exists a PLAN service, abort, which produces behavior similar to that of an invoked handler. Both are described in detail in Section 7.