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

[Ben Laurie]

On 1 April 2010 18:56, Mark Miller <erights at gmail.com> wrote:

> 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.
>

Well, that's a bug in the virtual file reader - if it is expecting an
operation to complete without error, then it should catch exceptions and
deal with them appropriately (in this case, converting EOF to an error).


>
> 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.
>

If I understand what's going on here, you're really just doing the
equivalent of classifying exceptions into "escapes" and "real exceptions",
and making it mandatory to handle escapes where they might be thrown. The
rest is syntactic sugar.


>
> 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
>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100401/7bca4f95/attachment.html