Re: Structured exception information

On Mon, 2007-01-29 at 21:15 -0500, Stephen Leake wrote:
Georg Bauhaus <bauhaus@xxxxxxxxxxxxx> 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.


.

Relevant Pages

  • Re: Structured exception information
    ... Tcl is a powerful language that is quite successful ... I said "Strings are the correct type for presenting information to the ... And yes, Ada exceptions ... But I don't understand _why_ you want to do that in the exception ...
    (comp.lang.ada)
  • Re: Question concerning object-oriented programming
    ... there has usually been a toString. ... I would prefer an exception thrown. ... Actual programmers are supposed to write code that verifies input. ... Educated middle-class people learn how to use language to ...
    (comp.programming)
  • Re: Rationale behind unwind-protect and double errors
    ... try/finally exception handling system. ... C++ programmers usually use destructors for the same purpose. ... handling, which does not use the mechanism you outline. ...
    (comp.lang.lisp)
  • Re: [ANN] Data Source Name parser (ODBC etc.)
    ... > suggested URL-like strings describing database connections. ... > library for such strings (data source names) is now available at ... raises the exception Syntax_Error. ...
    (comp.lang.ada)
  • Re: Exceptions
    ... Are you assuming current rules for guessing 10% exception handling, ... programmers. ... packge Subsys is ... return T raise Oops; ...
    (comp.lang.ada)