Re: Readability of exception handling

On 3/04/2014, at 3:28 PM, Alan Baljeu wrote:

> I agree with everything Richard writes, *except* the preamble:
> 
> From: Richard A. O'Keefe <[email protected]>
>> Exception handling in any programming language is paradoxical.
> 
>> You need to wrap an exception handler about code <<C>>
>> because you do not trust <<C>> to work properly.
>> But on the other hand, you *DO* trust <<C>> to do so
>> very little damage to its environment that it is safe
>> to continue.
> 
> 
> I believe it is best to consider the exceptions as *part*
> of "working properly".  I trust the code, and I understand 
> there are situations beyond the usual success/failure modes
> that need handling.

You may be forgetting that one typical use case for
exception handling is to guard yourself against someone
*else*'s code.  The code that raises the exception may
be code that did not exist when you wrote the exception
handler.

Indeed, that's exactly what the Prolog top level is doing.
It's running *our* code, not Jan's, and it really has NO
reason to trust that our code has not done radically
insane things.  It just tries to display a good error message,
pick it self up, and keep going, in the white-knuckled
*hope* that our code didn't corrupt anything important.

I concede that there are occasions when exception handling
is used as a form of long-distance control transfer.
Anyone who cares will find a long list of people who have
argued that that is an *abuse* of exception handling.
Lisp makes a clear distinction between catch/throw (which
is for long distance control transfer, not exception handling)
and the 'condition' machinery (which *is* for exception handling).
This is one of the reasons why I vehemently wish that the ISO
committee had accepted the earlier proposal (if_exception/3
and raise_exception/1, if memory serves) instead of the
catchier but historically abusive catch & throw.
In a language like Prolog, which has 'fail' built in, it is
much rarer to have a legitimate use for long distance control
transfer.