Re: Structured exception information

[Stephen Leake <stephen_leake@stephe-leake.org>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>>> 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. 

Good.

> 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.

Ah. Apparently you don't agree with me, or you missed my point.

Since bounced emails are not exceptional events, they should not be
handled by exceptions. Send_Mail should return status information, as
much as it wants to, for bounced emails; it should _not_ raise an
exception in this case.

>> 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. 

Well, I'd need to see an actual interface, as part of a real system,
to judge that.

If you are talking about the sensor system, then I _have_ seen real
examples of that, and it is not clumsy; it solves the problem of
possibly failed sensors quite nicely.

Basically, the result of any sensor read is a record:

type Sensor_Result_Type is record
    Quality : Quality_Type;
    Value   : Value_Type;
end record;

Any algorithm that deals with the sensor must be prepared for Quality
to be Bad.

Note that the algorithm is not just skipped; it probably uses an
estimate based on past values. Only when the sensor is Bad for some
finite time is it declared Permanently_Bad; then the system will
switch to the backup sensor, or an algorithm that does not use that
sensor.

> 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.

Say what?

Whether the status information is passed in an 'out' parameter, or as
part of a structured exception, or packed into an exception string,
the user still has to deal with it.

We are only discussing the parameter passing mechanism, not who is
going to deal with the information.

The same argument applies to the sensor system.

> The user of API must check the status later. 

Why "later"? Since bouncing is expected, that status must be checked
immediately; that's the point.

For the sensor, the quality is packaged with the value, they are
always examined together.

> This is a distributed overhead contaminating the code and violating
> the principle "here and now."

I'm not familiar with that principle of code design. As a lifestyle,
I've heard of it.

> 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.

I'm lost; which argument?

> 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.

Say what? Once the sensor has been read, all of the information is in
an object of Result_Type; there is no race condition in reading the
components of Result_Type.

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

What "problem" are you trying to solve?

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

I am arguing that exceptions should not be used when 'out' parameters
are more appropriate.

I am suggesting that in general, if you _need_ structured information
as the result of a subprogram, passing it in an 'out' parameter is
better than attaching it to an exception.

But others have posted convincing cases where that is not true. And it
appears the state of the art in exception mechanisms has improved, so
it's not such a large problem as I thought it was.

-- 
-- Stephe