Re: Structured exception information

[Maciej Sobczak <no.spam@no.spam.com>]

Stephen Leake wrote:

>>> Then what's wrong with a string?
>> Doesn't feel as type-safe as advertised.
> 
> But you have not given an actual example where a string is not
> a type-safe solution to the actual problem at hand.

Going this path a bit further, I find it difficult to convince myself 
that Ada is any better than, say, Perl. :-)

>> Sure. That's why there are more JavaScript programmers than Ada programmers.
> 
> I don't follow. Strings are perfectly valid Ada constructs. Why does
> the code to build the string not feel like Ada to you?

Again - going down this route, what's wrong with having only strings in 
the language? Tcl is a powerful language that is quite successful with 
only strings.

> You have not said _why_ you need to dismantle this information in the
> handler. What, _exactly_, will the handler do with the separate bits?

Looking up the localized error message in the dictionary based on the 
*type-safe* error code that it got from the exception object, probably?

>> Still, that's not what I expect from Ada.
> 
> Lots of people expect lots of things.

And lots of them find these things in other languages.

> Sometimes, those expectations
> are unreasonable, and should be changed.

Sometimes, yes.

> That's what I'm trying to
> explore here; I think expecting anything other than a string for
> exception data is unreasonable.

I expect *type-safe* error code which I can look up in the dictionary.

> So far, you have presented no case to show I am wrong.

I'm looking forward to see a convincing solution for error code and the 
dictionary.

>>> As a general matter of user-interface design, I would find that
>>> annoying. As a user of a system, the only thing I want from an error
>>> message is either "how do I fix this myself" or "how do I report this
>>> to the maintenance team".
>> That is a reasonable approach and will work fine most of the time, 
> 
> When will it not work? I have never encountered such a case.

It will not work in those cases where the handler might attempt to "fix 
things" and retry the operation that failed instaed of displaying the 
"sorry" message.
Consider for example a compuational algorithm that failed to allocate 
some memory that was needed for computations. Exception is raised and 
goes up to the handler that as a first attempt tries to flush some 
in-memory caches or other transient buffers and restarts the computation 
with the hope that it can now succeed with more memory available in the 
system. There is no need to display anything to the user and string 
format has no use here. Even for this simple case I can imagine that the 
code in question can include in the exception object the size of the 
allocation that failed, so that the handler can make more optimal 
decisions as to what should be flushed. In such a case, I'd expect the 
size information to retain the type safety that should be there from the 
very beginning.

> If you look into the details of "structured exception handling" in
> other languages and implementations, they have bugs, and fundamental
> flaws in design.

Ada does not have this, because it *might* be difficult for 
implementers? Is it better if programmers find it more difficult to 
write final programs instead?

> That is why Ada did not go that way. Ada is _much_
> more careful about getting the core design right

It failed in this aspect.

> allowing fully
> robust and safe implementations of _all_ features

Is there anything in Java or C++ or Python or whatever exception 
handling that makes it fundamentally impossible to implement correctly?

> especially in
> multi-tasking and multi-processing environments.

Why should I care about multi-tasking and multi-processing environments 
when writing single-tasking programs? Should I be constrained in my work 
just because some feature might be difficult to implement elsewhere?
I'd say no, but just in case I propose an easy solution for everybody: 
just forbid structured exceptions in multitasking and distributed 
environments and allow them where they will naturally work.
BTW - somehow Java exceptions work fine in a distributed environment, so 
there is a proof that such thing is possible.

> So if you find yourself fighting Ada to do something, you need to step
> back and think more carefully about _why_ you are doing it that way.
> Ada is telling you it is inherently unsafe.

Sorry, I don't buy this. I stepped back, thought more carefully and I 
haven't seen any solution for looking up error code in a dictionary or 
for transmitting size information so that the handler can make optimal 
decisions before retrying memory-expensive computations.

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/