Retrying exceptions - was 'Coding with errors in mind'

[leichter_jerrold at emc.com (Leichter, Jerry)]

On Fri, 1 Sep 2006, Jonathan Leffler wrote:
| Pascal Meunier <pmeunier at cerias.net> wrote:
| >Tim Hollebeek <tholleb at teknowledge.com> wrote:
| >> (2) in many languages, you can't retry or resume the faulting code.
| >>     Exceptions are really far less useful in this case.
| >
| >See above.  (Yes, Ruby supports retrying).
| 
| Bjorn Stroustrup discusses retrying exceptions in "Design and Evolution of 
| C++" (http://www.research.att.com/~bs/dne.html).  In particular, he 
| described one system where the language supported exceptions, and after 
| some number of years, a code review found that there was only one 
| retryable exception left - and IIRC the code review decided they were 
| better off without it.  
This is an over-simplification of the story.  I may get some of the
details wrong, but....  This dates back to work done at Xerox PARC in
the late 70's-early 80's - about the same time that Smalltalk was being
developed.  There was a separate group that developed system programming
languages and workstation OS's built on them.  For a number of years,
they worked on and with a language named Mesa.  Mesa had extensive
support for exceptions, including a resumption semantics.  If you think
of exceptions as a kind of software analogue to a hardware interrupt,
then you can see why you'd expect to need resumption.  And, indeed, the
OS that they built initially used resumption in a number of places.

What was observed by the guys working on the system was that the number
of uses of resumption was declining over time.  In fact, I vaguely
remember that when they decided to go and look, they were using
resumption in exactly two places in their entire code base - OS,
compilers, windowing system, various tools.  (Exceptions were used
extensively - but resumption hardly at all.)

It's not that anyone deliberately set out to remove uses of resumption.
Rather, as the code was maintained, it repeatedly turned out that
resumption was simply the wrong semantics.  It just did not lead to
reliable code; there were better, more understandable, more robust
ways to do things that, over time and without plan, came to dominate.

Somewhere, I still have - if I could ever find it in my garage - the
paper that described this.  (It was a retrospective on the effort,
almost certainly published as one of the PARC tech reports.)

Mesa was replaced by Cedar, which was a simpler language.  (Another
lesson was that many of the very complex coercion and automatic
conversion mechanisms that Mesa weren't needed.)  I think Cedar
discarded Mesa's exception resumption semantics.  Many of the people
involved in these projects later moved to DEC SRC, where they used
the ideas from Mesa and Cedar in Modula2+ and later Modula3 - a
dramatically simpler language than its older Xerox forbearers.  It
also used exceptions heavily - but never had resumption semantics.
Much of the basic design of Java and C# goes back to Modula3.

|                         How much are retryable exceptions really used, in 
| Ruby or anywhere else that supports them?
Not only how much are they used, but how well do they work?  Remember,
if you'd look at *early* instances of Mesa code, you might well have
concluded that they were an important idea.  It may well be that for
quick one-off solutions, resumption is handy - e.g., for building
"advise"-like mechanisms to add special cases to existing code.  But as
we should all know by now, what works in-the-small and in-the-quick is
not necessarily what works when you need security/reliability/
maintainability/supportability.
                                                        -- Jerry