In order to cope with situations where a function should not return normally, either as a result of a semantic error such as division by zero or at the user's request, Nickle provides support for the declaration, generation, and handling of exceptions. Exceptions are not first-class objects. They are declared in the style of void functions (including arbitrary typed formal parameters), and are scoped identically. At any point during program execution, any in-scope exception may be thrown via a raise statement. A Java-style try-catch block allows the handling of raised exceptions. Currently, there is no mechanism for ``restarting'' a computation which has raised an exception: once an exception has been raised, execution will resume at the nearest applicable dynamically enclosing catch, or at the top level if none is found.
In addition to exceptions, Nickle provides first-class ``continuations'', which capture an execution locus and environment. These are not true continuations, as they do not restore the values of variables modified by assignment between the capture of a continuation and its use: however, the actual semantics supported is both much cheaper to execute and arguably more usable for an imperative language. The closest C analog is setjmp()/longjmp() (and indeed, the Nickle equivalents share these names). However, unlike C, a longjmp() can occur anywhere, not just in a dynamically enclosing function. In addition, since the Nickle primitives are builtins rather than library functions, variables modified between a setjmp() and a longjmp() have well-defined values after the longjmp().1