[cap-talk] Video of Marc Stiegler's talk at Google : "The Lazy Programmer's Guide to Secure Computing"

[Mark Miller]

On Thu, Apr 1, 2010 at 9:24 AM, Bill Frantz <frantz at pwpconsult.com> wrote:

> On 4/1/10 at 8:54 AM, erights at gmail.com (Mark Miller) wrote:
>
> > [...] As I define these terms, throwing an
> > exception is a fail-stop loss of progress. Hanging is a fail-safe loss of
> > progress.
>
> Now I'm very confused. The exception that seems to me to be an exception
> to this statement is the "End of file" exception that some language
> runtimes through when reading beyond the end of a file. Most programs in
> those languages that process entire files sequentially need to have this
> exception thrown and successfully caught in order to correctly make
> progress toward their "after reading the entire file" logic.
>
> My feeling is that exceptions are unusual events, not necessarily
> errors.


Thanks for uncovering an assumption I was making but forgot to state. Using
thrown exceptions for such unusual-but-not-erroneous events is inherently
error prone. The problem is that thrown exceptions cross levels of
abstraction on their way "out", while the use of type-based discrimination
of catch behaviors make (usually) unwarranted assumptions about the level of
abstraction from which the exception was thrown.

To take your example, say I am implementing a File interface to create a
virtual file mapped onto multiple less virtual nderlying files. Say that a
bug in virtual file read causes it to read past the end of one of the
underlying files. The underlying file abstraction correctly reports the
unusual condition. To the virtual file read operation, this is actually an
erroneous condition. However, when this complaint propagates to the caller
of the virtual file read, this caller takes it to be a signal that the
virtual file is properly reporting an unusual but expected condition.

In E and my preferred style of using Smalltalk, we use generative non-local
exits for such conditions. (These are available in Cajita as well, but not
(yet?) in JavaScript. <
http://wiki.ecmascript.org/doku.php?id=strawman:return_to_label>) IIRC, the
"escape" special form used by E was first invented by John Reynolds in the
late '60s. In E, your example API might be used as

    escape onEnd {
        ... file.read(37, onEnd) ...
    } catch arg {
        .... arg ...
    }

escape creates a one-optional-argument function known as an ejector and
binds it to the pattern in its head, here the variable "onEnd". onEnd is
then in scope during execution of the escape body. If onEnd is called during
execution of this body, control flow within this body terminates and control
transfers to the catch clause, with the argument to the onEnd function call
bound to the catch pattern, here the variable "arg", which is then in scope
during the catch body. The non-local exit represented by the above code is
generative -- each time this escape expression is evaluated, it generates a
fresh non-local exit point. Thus, nested usage has no danger of unintended
aliasing.

Thus, in E, we fall back to throwing an exception only in the "something bad
happened, get me out of here" case.

In languages not supporting generative non-local exits, the distinctions I
am trying to draw are indeed muddled.



> Of course, many exceptions should be treated as errors, but a
> complete treatment of exceptions needs to cover the ones that aren't
> errors. This treatment is greatly complicated by the fact that an
> exception may be an error in some programs while the same exceptions is
> not an error in other programs. The classic example is some scientific
> processing which uses a quick algorithm unless it gets an exception
> (e.g. divide by zero or significance loss), in which case it uses a
> slower algorithm which doesn't raise those exceptions.
>
> Cheers - Bill
>
> ---------------------------------------------------------------------------
> Bill Frantz        |"After all, if the conventional wisdom was working, the
> 408-356-8506       | rate of systems being compromised would be going down,
> www.periwinkle.com | wouldn't it?" -- Marcus Ranum
>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>



-- 
Text by me above is hereby placed in the public domain

   Cheers,
   --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100401/34040a71/attachment.html