[Lrde Annonce] 90' session at ACCU 2013 on "The Bright Side of Exceptions"

Hello, and happy new year to everyone! I'm pleased to announce that I will be holding a 90 minutes session at the next ACCU conference in Bristol. The abstract is given below. The Bright Side of Exceptions 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 favorite 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 signaled 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. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre, France Tel. +33 (0)1 44 08 01 85 Fax. +33 (0)1 53 14 59 22