Re: [Gnu-arch-users] Nit

[Tom Lord]

    zander:
    > A more mature; "I understand, but [Java-esque exceptions are]
    > not for me" would not leave such a foul taste in my mouth.

(See the postscript below my signature, but:)

Whether or not it is "for me" is not the issue.  The issue is
objective and can be restated as follows:

In systems based on Java-style exception handling the addition of a
new exception type to those that can be generated by a given method
can silently turn some callers of that method from correct to
incorrect (and even dangerous).  Static checking in the form of
Java-esque `throws' declarations catch some but not all such errors.
To use a system like Java safely(!), when writing general-purpose
libraries, programmers must adopt a discipline of catching all
exceptions at each call-site, rethrowing only those which they
deliberately wish to permit from that call-site.  (Code which is not
"general purpose" does not, of course, require that.)

The discipline required of a general-purpose library author to use
Java exceptions safely is, therefore, essentially the very same
discipline required to use error-codes safely: check for every error
you know about and handle the case when you got a "surprise" error, at
_every_call_.  Similarly, automated static or dynamic checking to help
ensure the safety of exception-using code always has an exact analog
in the checking needed to help ensure the safety of error-code-using
programs.

In other words, on the issues of safety and convenience, there is no
advantage of exceptions over error-codes: they require the same work
at every call-site and admit equivalent static and dynamic checking.
Robust code is doomed to be (often) verbose, tedious, and ugly, either
way: it has to check for every possible error, and it has to
explicitly handle the case of an unexpected error.  (If anything, the
error-code approach has some syntactic advantages here.)

The final distinction between exceptions and error-codes is flow
control: exceptions make non-local exits while error-codes do not.
However, once we realize the need for a discipline of call-site error
filtering to use exceptions robustly, this issue disappears:
exceptions employed with a discipline of call-site error filtering
_do_not_perform_ non-local exits -- they can be replaced by a
`return'.  Once that discipline is employed, exceptions are, in
essense, reduced to error codes!

That observation, that exceptions, if employed in a general purpose
library robustly, function _exactly_ like error codes has to be
reconciled with another seemingly contradictory observation: non-local
exits are _useful_ if you know what you're doing with them.

But that's easy to reconcile: provide non-local exits independently of
exceptions.  C has setjmp/longjmp; Scheme has
call-with-current-continuation and tail call optimization ---
separating out control flow from exception handling works just fine.
The safety problems with Java-esque exceptions arise precisely because
it performs non-local exits (to a dynamically scoped handler): an
error interface that makes that mistake harder to commit is an
improvement.

It seems downright wrong to me to provide even only upward-only
continuations only via the exception mechanism, as Java does.   
A non-local exit is not necessarily an exception!


-t


p.s. If, on the other hand, you're really here to wave your arms
  around and say "Tom's a Jerk" and leave in a huff (or an minute and a
  huff), well, you're joining a fine tradition and a long line so you'll
  have to do it in a pretty pithy way if you want to stand out :-)

  You wrote:

    > A more mature; "I understand, but [Java-esque exceptions are]
    > not for me" would not leave such a foul taste in my mouth.

  Well, please have the good taste to recognize that, especially
  across the internet, not least across language and cultural
  barriers, that that "foul taste" may very well be nothing more than
  an emergent property of the communications process reflecting poorly
  on neither party, and best responded to by a tasteful grace rather 
  than a tedious defamation.