Re: Structured exception information

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

Georg Bauhaus <bauhaus@futureapps.de> writes:

> On Sat, 2007-01-27 at 13:17 -0500, Stephen Leake wrote:
>
>> In addition, you have ignored the problem that each version of
>> Write_Output for different hardware will need need a corresponding
>> version of the exception type; more work.
>
> Versions of Write_Output for different hardware might also
> need a different string passed with the exception? 

There is one Write_Output for each hardware type, so that's what
happens now.

> For example in order to clearly indicate which hardware is
> reporting. I'm not so sure a different type is needed for every
> variation in hardware. A serial number component might do, if the
> hardware is sufficiently similar.

Yes, if there are 5 Analog_Output cards in the system, each one has a
name or number, and that is included in the exception string.

> Why is it better to have this setup that seems more complicated?
> (Isn't it strange to hear an Ada programmer ask why it is
> better to not just lump information into a string? :-) :-)
> Now who best writes the messages (1), what should be included (2),
> and where in the program should they be formatted(3)?
>
> (1) Programmers tend to leave out necessary context information
> judging by the brief shouts of command line tools that have
> caused so much anger and Google searches for explanations.
> Natural language experts aren't usually available during
> development, so it seems an advantage to add another level of
> indirection, just provide the information, and delegate the
> formulation of messages to the domain experts.

Hmm. I agree that some members of my team have not yet learned how to
write good error messages. The solution is to educate them :). Or to
have someone who is good at it review and fix the messages.

Based on other examples of whole manuals written by someone other than
the programmers, I don't think that approach will produce good error
messages. 

Have you worked on a real system where this approach was used, and was
in fact better than having the programmers write the error messages?

> (2) How can a programmer anticipate how the information
> "raised" from his/her module is best used elsewhere?

Because there is a system design. Without a system design, you cannot
do error messages correctly. 

> E.g., MS recommends not to show stack traces from failing
> ASPx programs to end users. 

Good advice. I have the same policy.

> Perhaps show a nice page with some error code and an invitation to
> report or come back later. But what can an Ada exception handler do
> here if all exception information is already frozen inside a string?
> Parse it?

There are no stack traces in the messages I've shown. 

The system design says exception handlers only have to add
information, never subtract it.

If all programmers follow the system design, there will never be
inappropriate information in an exception message. 

If some programmer doesn't follow the system design, educate them!

> (3) As you have explained, SPO sentence construction rules are
> not universal. The usual approach is therefore to use sprintf-
> like procedure calls for message construction. Yet, whatever the
> grammar rules of a natural language might require, the
> information available *for* message construction is unchanged
> by the fact that it can be turned into a sentence. So why not
> create or extend a type for the information and pass objects
> of the type, not formatted strings?

"Why not"? Because it's easier not to! That is the topic of this
thread. 

> In summary, then, I would prefer the separation of typed exception
> data and exception message strings. The first is far more flexible

It is far _less_ flexible! that is the point. Any pre-defined type
structure is (by definition!) less flexible than a string. I can put
_anything_ in a string; I can only put the pre-conceived classes of
information in a structure. So when I write the Write_Output for my
wizzy new piece of hardware, I will _also_ have to extend the
exception class; not worth it.

> and accessible for anyone but the lazy programmer who writes the
> exception message strings after "with" ;-)

"accessible" meaning "easy to change some details of the
presentation", yes. But I remain unconvinced that small gain is worth
the cost. Except for internationalization support, which can be done
with strings as well.

-- 
-- Stephe