wiki.accu.org

Back to proposals-2013

Title: The bright side of exceptions
Proposer: didier_verna
Type: Presentation
Duration: 90 minutes
Description: In many programming languages, the term “exception” really means “error”. This is rather unfortunate because an exception is normally just something that does not happen very often; not necessarily something bad or wrong.

Some ancient languages like C don't support exceptions at all. You need to indicate them with specific return values from functions. Languages with explicit support for exceptions (e.g. Java, C++ or Python) provide built-in facilities for handling them. The most traditional approach to this is the “try/catch/throw” system, whatever it may actually be called in your favourite language. As it turns out, this system suffers from limitations which affect its usability in complex situations. The two major problems are 1. the obligatory stack unwinding on error recovery and 2. a two-levels only separation of concerns (throwing / handling).

In this talk, we will demonstrate the benefits of using a system which does not suffer from these limitations. More precisely:

- the stack is not necessarily unwound on error recovery, which means that the   full execution context at the time the error was signalled is still   available,

- the separation of concerns is 3-fold: the code that signals an error (throw)   is different from the code that handles the error (catch) which itself is   different from the code that chooses how to handle the error (restart).

It turns out that an exception handling mechanism like this is able to handle more than just errors and in fact, even more than just exceptional events. In Lisp, this system is called the “condition” system. Conditions are the bright side of exceptions: not necessarily bad, not even necessarily exceptional. Conditions become an integral part of your programming paradigms toolkit. We will provide two examples of “condition-driven development”. The first one will show how to handle actual errors, only in a more expressive and cleaner fashion than with a regular try/catch/throw system. The second example will demonstrate the implementation of something completely unrelated to error handling: a user-level coroutine facility.

Roger: Yes - looks like an interesting talk