On Fri, 1 Sep 2006, Jonathan Leffler wrote: | Pascal Meunier <[EMAIL PROTECTED]> wrote: | >Tim Hollebeek <[EMAIL PROTECTED]> 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 _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php