wiki.accu.org

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Back to [[conference:committee:proposals-2013]]\\
\\
**Title**: The bright side of exceptions\\
**Proposer**: [[2013: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