Re: Structured exception information

[Robert A Duff <bobduff@shell01.TheWorld.com>]

(By the way, one of my other posts crossed a couple of yours,
so if it sounds like we're talking past each other, it's because
we were both typing at the same time.  ;-) )

Stephen Leake <stephen_leake@stephe-leake.org> writes:

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

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

Precisely!  Clearly we can both agree on this point.  ;-)

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

OK, that's another valid way to look at it.

But note one key point: the place you're jumping to is determined via
dynamic scoping.  It's not like Pascal, where you can goto a label
outside the current procedure, and that label has to be (statically)
visible.  An exception is a goto, but you don't know where you're
going to -- you often are going to someplace invisible at the "raise".

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

My point is that this decision can be taken differently for different
clients (of the thing that raised the exception).  I agree it's
"upfront", but it's a separate design decision for each client.

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

What do you expect?  This is just a friendly usenet discussion.  ;-)

I plead guilty to using "etc" to mean "I want to pretend there are many
more issues, but I'm too lazy to think of any right now."  ;-)

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

Indeed.  It's unhelpful if the language gets in the way, though.

You made several other interesting points, but I think I'll leave it at
that -- this post is long enough.

- Bob