Re: Structured exception information

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

Maciej Sobczak <no.spam@no.spam.com> writes:

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

That's absurd.

I said "Strings are the correct type for presenting information to the
user".

My full system uses strings for that purpose. It uses many other
types for other purposes; quaternions for orientation, unbounded
arrays for dynamic lists, binary trees for sorted symbol tables, hash
tables for fast lookup of symobls, a class hierarchy with abstract
operations for models, records with bit-level representation clauses
for hardware registers. Etc. 

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

Why would it do that? The original problem was "present this
information to the user".

Again, I'm asking for a _detailed_, _real_ example!

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

Well, ok, that's a fairly clear requirement. And yes, Ada exceptions
cannot include a type-safe error code.

But I don't understand _why_ you want to do that in the exception
handler. Why didn't the callee look up the error code, and put the
string in the exception message?

What will the exception handler do with the result of the lookup?

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

You have not defined "dictionary" here. If I assume it just contains
strings, and the handler will simply output that string to
Standard_Error, then having the callee do the lookup is a perfectly
reasonable solution.

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

Ok, that's a concrete example. Thank you.

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

Not "might be difficult", but "is impossible to get truly right in
_all_ cases required by the language". Hmm. "impossible" may be too
strong. "we know of no way to do it" is probably closer. As Randy has
been saying, now that the rest of Ada has evolved, it may be that we
now _could_ find a way to have structured exceptions in the next
version of Ada.



> Is it better if programmers find it more difficult to write final
> programs instead?

Yes! 

Let's be clear. Here are the choices:

1) Define structured exceptions in Ada. We _know_ that _all_ compilers
will not meet the standard in some way, and each in different ways.

2) Define only strings for exceptions. Let the programmers use other
methods to solve particular problems.


In case 1), I will never be able to rely on the exception information,
so I will only use strings anyway.

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

Well, you are interpreting "right" to mean "has everything I want"; I
meant "is internally consistent, has no unexpected behaviors, has a
reasonable implementation approach".

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

Yes, which is why none of those implementations fully meets the
standard, and each implementation differs from the others, sometimes
in subtle ways.

>> especially in
>> multi-tasking and multi-processing environments.
>
> Why should I care about multi-tasking and multi-processing
> environments when writing single-tasking programs? 

Well, that is a reasonable point. Ada made the choice to make
multi-tasking work right, as part of the language. So you may want to
choose another language, if this particular choice make Ada unsuitable
for you. 

> 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 

By "fine" do you mean "i've never had a problem with them" or do you
mean "everyone who has studied these issues in depth agrees that the
Java implementation will _never_ have a problem"?

Those are two very different statements. I prefer a language that uses
the second approach.

The Java class libraries have lots of deprecated procedures, that
"worked fine" when they were first released, but had problems of one
sort or another when people tried to use them in unanticipated but
clearly reasonable ways. Ada tries very hard to avoid that sort of
thing, especially in the core language.

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

In Ada, you need to pass back an error code of some type, or the size,
not use an exception. That is a valid solution. Using exceptions for
this is inherently unsafe.

-- 
-- Stephe