Re: Structured exception information

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

Georg Bauhaus <bauhaus@arcor.de> writes:

> On Mon, 2007-01-29 at 21:15 -0500, Stephen Leake wrote:
>
>> 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!

Ok, so the answer to my question is "no".

There certainly was a problem, but it appears that structured
exceptions were not accepted as a solution. On the other hand, neither
was programmer education, so apparently we are both wrong :).

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

Yes, I have said that designing exceptions for libraries intended to
be used in a wide variety of systems is hard. In that case, it might
be useful for the library to define a structured exception type. But
it might be even better to provide status instead of exceptions.

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

So I'm talking about having control over the _entire_ system, and you
are talking about third party libraries. That is different.

-- 
-- Stephe