Re: Structured exception information

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

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> I don't follow. Strings are perfectly valid Ada constructs. Why does
>> the code to build the string not feel like Ada to you?
>
> Building strings is fine.  Requiring clients to parse them is evil --
> not type safe.

Well, "evil" is a judgement (more below). I agree with "not type safe".

> The whole point of exceptions is to separate the detection of potential
> errors from the handing of them.  

Well, that's one view. I don't think that's consistent with the
current definition of exceptions in Ada. Which is the point of this
thread, I guess :).

I think the point of exceptions is non-local transfer of control. A
low-level routine encounters a problem, that only some routine several
layers up is prepared to handle. Rather than passing status thru each
layer, you raise an exception, and jump directly to the right place.

> A well-designed exception mechanism would allow the client to make
> these decisions:
>
> Is this condition really an error?
>
> If so, is it a recoverable error, or is it a plain old bug?
>
> If recoverable, what should I do?

That's a reasonable list. My current project does make those
decisions, based solely on the exception names. 

I have not thought very hard about whether it could make better
decisions if it had more information. So far, I'm happy with the
decisions it is making.

> If it's a bug, should I print out useful information?  Useful to the
> user, or useful to the programmer who wants to fix the bug (or both)?

That's an upfront design decision, not a run-time decision.

> (Example: if the gnat front end detects a bug in itself, it prints
> out the line number it was processing at the time, which is useful
> to the user who wants to find a workaround.)

Right. And that is a design choice was made by AdaCore, not a run-time
choice of the compiler; the compiler does not do that for some bugs,
but something else for other bugs.

> Granularity of handling -- do I want to handle all I/O errors,
> or just the "disk full" error?

I think you are hinting that you want classes of exceptions, rather
than single names. I agree I would find that useful sometimes. 

In Ada, we get this only by including each name in an exception choice
list. Ugly, but functional.

> Etc.

That's always a fun word. I doubt that the things I extrapolate here
are the same ones you do :).

> Constructing a string at the "raise" point is wrong because it presumes
> that the client wants to print a string 

That is the overall design of my application, so it is correct in this
case.

Designing a library that will be used by unknown future applications,
yet still returns truly useful information in error cases, is a very
hard problem. 

> and exit, 

Not in my application. Some exception names indicate fatal bugs that
require exit, others indicate a user error that require "stop, let the
user change something, try again".

Again, that is the overall design of my program.

> and it presumes the format of that string. 

No, since the string is never parsed by the program, only by the user
(a much more flexible parser :).

Hmm. I do have some formatting conventions; if a file is involved, I
format the file name, line number, and column information using the
Gnu standard, so Emacs parses it easily. 

VMS had a binary file format for error messages from the compiler,
that LSE could interpret. Other programs could output that same format; it
was a VMS standard. That is an example of structured information, vs
the Gnu standard of formatted strings. It appears that the market has
voted for formatted strings in this case :).

> If that were OK, then why have exceptions -- why not make the code
> that detects the error print a string and exit?

See above. In addition, in the case of fatal errors, there is cleanup
work to be done; shutdown external sockets, terminate other tasks. 

I suppose you could leave all that to the operating system, but I
choose not to. I get better error messages this way, so I have a
better chance of fixing the problem.

> Suppose we want to print error messages in French.  If the "raise" point
> constructs a message in English, the client can't make that decision.

Yes, that is what Internationalization libraries attempt to
accomplish. I have not investigated doing that in depth (it is _not_
a requirement for my current project). What little I have heard about
this sounds like it is impossible to get truly right; at best you must
impose very strict rules on formatting of all messages, and use some
sort of codes rather than any natural language when constructing the
messages.

That is a case where the error information is structured, rather
than a flat string. So doing that with exceptions in Ada may be
difficult. On the other hand, I think the Gnu internationalization
libraries use formatted strings for this.

Randy often says "sometimes you have to go outside the language" in
order to get something useful done. It may be that error handling is a
case where it is appropriate to forgo type safety, because of all the
other practical issues that come up. Let's remember that type safety
is a means to writing programs more efficiently, not an end in itself.
If it gets in the way of writing programs efficiently in some limited
area, it should be relaxed in that area. That seems to be the case
here.

-- 
-- Stephe