Re: Structured exception information

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 20 Jan 2007 10:04:07 -0500, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Fri, 19 Jan 2007 04:47:28 -0500, Stephen Leake wrote:
>>
>>> Maciej Sobczak <no.spam@no.spam.com> writes:
>>> 
>>>> Doesn't feel as type-safe as advertised.
>>> 
>>> But you have not given an actual example where a string is not
>>> a type-safe solution to the actual problem at hand.
>>> 
>>> The only example you have given is "present the error to the user". In
>>> that case, a string is precisely the correct type.
>>
>> What about presenting an information necessary for handling the exception
>> to the handler?
> 
> Ok, I would still like to see a precise example, not all this hand-waving.

I wished to stay at the level of vagueness of "present the error to the
user." (:-))

>> As a practical example, consider mail non-delivery. A returned mail plus
>> traceback is the information to you, the handler from the exception point.
> 
> To me, bounced emails are _not_ "exceptional" events in mail handling
> systems; they are expected, even "normal".

We agree on that. But that is not the problem we are discussing. Which
simplified is whether an API procedure Send_Mail should add a non-string
information to the Delivery_Error exception, or else pack it in a String. I
prefer the former.

> As for the failed
> temperature sensor in another thread, out-of-band status information
> is a cleaner way to handle this.

I don't think so, that would make interfaces very clumsy. Further it is a
bad design, because it eludes to face the problem by putting all the
responsibility to deal with on the user's shoulders. The user of API must
check the status later. This is a distributed overhead contaminating the
code and violating the principle "here and now."

Note, even if we considered a middleware layer, in which the sensor
variable would indeed have a status field and a lot of other fields to make
the internals working, even in this design, the argument would still hold.
Because then, when accessing such variable object, one would again need an
exception and an information about the status in it. Otherwise one would
have quite nasty race condition issues when accessing such variables - you
check the status, get preempted and then read a rubbish value.

The point is, you have just moved the problem, you didn't solve it.

And last but not least, it is an argument against exceptions in general and
thus irrelevant here.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de