Re: Structured exception information

[Georg Bauhaus <bauhaus@arcor.de>]

On Mon, 2007-01-29 at 21:15 -0500, Stephen Leake wrote:
> Georg Bauhaus <bauhaus@futureapps.de> writes:

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

Yes, I should have said that I meant the set of all people
involved in exception raising and exception handling in the
broadest sense of the term.

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

I worked on a system involving 3 companies where one style of
exception handling was to be silent about them (empty handlers).
Another style was to write a few words that could be understood
by the programmer who wrote the handler because he knew the
context. These were (are, I think the programs are still up and
running) communicating programs, no source code was exchanged.

But when the exceptions were reported as strings into some log
some of us on all sides were out of luck. Strings are too easy
to write. People didn't give them enough attention, and they
didn't create exception types either even when this was possible
(in Java). And you don't ask for education across company borders
if there is a hierarchy. Let alone speak of education!



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

Adding information is good, and the advice also needs to mention
that exceptions raised *do* have to provide some information :-)


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

I'm not so sure what is easier to do, write a good exception
message or build up an exception object containing the necessary
information about what happened. It seems easier to just write an
exception message string. Easy programming. But once it is written,
the information is as inflexibly coded as can be: You need parsing
if you have to extract it. I need to extract it if and when I
cannot change what a 3rd party library is reporting. There just
is no "education" or telling them what they should write in
exception messages.

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

Certainly _you_ can place anything inside an exception message string.
(To say a few absurd things, for example a Tcl program. No problem.
I could even suggest that we use Storage_Element_Array instead of
String for the message as this helps preserving memory layouts... :)
 As a user of your exception message I get something that is carved in,
well, a String. As a user of an exception object of an exception type,
I'll have the necessary information at my disposal (hopefully).
For me then this is more flexible and easier than parsing message
strings.


>  Except for internationalization support, which can be done
> with strings as well.

Uhhhm. Anything can be done with strings, as Tcl is demonstrating,
but why do we use Ada where is can be done better using object of
type. A type for internationalized messages is easy to spot in a
program and can be arranged for Ada coverage rules. So you get
builtin language checks. If you use just strings, it will work, but
you have to use another language processor for scanning message
strings reliably. This may work in practice, with proper discipline
and heavy scanning, but I think it works around a better solution,
one that makes use of the Ada type system.