[erlang-questions] Package Support/Use

Thomas Lindgren thomasl_erlang@REDACTED
Tue Nov 7 15:02:52 CET 2006

--- "Richard A. O'Keefe" <ok@REDACTED> wrote:

> Any rate, as the person who designed and implemented
exception handling
in Quintus Prolog and single-handedly installed
exception reporting
throughout the entire QP system and library, I am not
opposed to 
as such.  What I am opposed to is designing in the use
of exceptions
without *thinking* about them, and specifically
without thinking about
whether a particular outcome really is exceptional or
should be handled
as part of normal control flow.  One way to think
about it is this:

    if this outcome occurs, would I be happy for the
entire calling
    process to drop dead (with a suitable error

If the answer is "yes", then an exception is probably
the right thing."

(Sorry about the sloppy quoting.)

It's somewhat drastically put, but basically I agree. 
I won't claim the following is a universal property,
but at least it turns up often enough in my code. 

Higher-level handlers can only do so much when an
exception arrives, e.g., log that "some file operation
returned this POSIX error" or whatnot. This is because
most of the context has been lost when the exception

This tends (in my experience) to push sensible error
handling or reporting fairly close to the source of
the exception. And as we get closer, tagged values
start getting more attractive.

I'm not sure if there is a good way out of this
semi-dilemma for Erlang. Some languages (Common Lisp
and Smalltalk, I believe) use a related concept,
"conditions", for error handling, which might be of
interest. Perhaps conditions could be adapted to
Erlang (smart exceptions have a sketch of how to do
this, but it would need some development to work
cleanly). It's anyone's guess whether such a rewrite
would be backwards compatible, of course.


Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail.

More information about the erlang-questions mailing list