Re: Structured exception information

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

On Tue, 23 Jan 2007 02:28:12 -0500, Stephen Leake wrote:

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

Oops, then you reject use of exceptions here. That would be a different
discussion then.

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

Good, let's drop that E-mail stuff, because sensors seem to be closer to
both of us.

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

I don't think so. From a system-wide perspective, yes, sure, but locally I
have a problem with that. Let's consider:

   function "+" (X, Y : Sensor_Result_Type) return Value_Type;

We have to discard this on the same reasons (if we had accepted them (:-))
and replace it with:

   function "+" (X, Y : Sensor_Result_Type) return Sensor_Result_Type;

Now, before we would rush into developing a home-brewed IEEE arithmetic.
May I ask you, how Quality_Type compose under "+"? I know what 1+2 is, but
what is (1, Try_Again) + (2, Change_Battery)?

(2, First_Change_Then_Try)? (:-))

> Note that the algorithm is not just skipped; it probably uses an
> estimate based on past values.

Yes, these are not exceptional states, they are parts of some composite
value. Nobody would implement that using exceptions. It would be like file
Read raising exception on each read character and returning EOF if there
were no one. (:-)) Let's don't consider measurement errors and concentrate
on hardware faults.

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

OK, this is a third case. Timeouts are handled in a similar way. Before an
exceptional state is entered one ignores the data/service quality assuming
that everything is alright, because no reasonable estimation could be made
anyway before the timeout expires.

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

Full agreement.

But the mechanism of passing is very different. In case of exceptions it is
fully transparent for the layers where the exception is being propagated
unhandled. A big difference.

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

See the example with "+".

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

Actually your Sensor_Result_Type is exactly what I had in mind.

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

Consider it a protected object, with Get_Quality and Get_Value functions.
(a middleware is a kind of bunch of such objects)

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