gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] Re: Nit


From: Tom Lord
Subject: [Gnu-arch-users] Re: Nit
Date: Tue, 21 Oct 2003 20:07:45 -0700 (PDT)



    > From: Miles Bader <address@hidden>

    > BTW, here's a quote from `A History of CLU'* about exception handling:

    [....]
    >    CLU's mechanism is unusual in its treatment of unhandled exceptions.
    >    Most mechanisms pass these through: if the caller does not handle an
    >    exception raised by a called procedure, the exception is propagated
    >    to its caller, and so on.  We rejected this approach because it did
    >    not fit our ideas about modular program construction.  We wanted to
    >    be able to call a procedure knowing just its specification, not its
    >    implementation.  However, if exceptions are propagated automatically,
    >    a procedure may raise an exception not described in its
    >    specification.

Excellent.   In those terms, the flaw in Java, changing the last
sentence slightly, is:

        However, if exceptions are propagated automatically, a
        procedure may raise an exception that was not described in
        its specification at the time its caller was compiled, provided
        only that the caller itself was declared to possibly raise 
        an exception of the same class or a superclass of that class.




    >    Although we did not want to propagate exceptions automatically, we
    >    also did not want to require that the calling procedure handle all
    >    exceptions raised by the called procedure, since often these
    >    represented situations in which there was nothing the caller could
    >    do.  For example, it would be a nuisance to have to provide handlers
    >    for exceptions that ought not to occur, such as a bounds exception
    >    for an array access when you have just checked that the index is
    >    legal.  Therefore, we decided to turn all unhandled exceptions into a
    >    special exception called "failure" and propagate it.  This mechanism
    >    seems to work well in practice.

That part is just a (probably quite sensible) syntax optimization.

-t




reply via email to

[Prev in Thread] Current Thread [Next in Thread]