Re: Structured exception information

Maciej Sobczak <no.spam@xxxxxxxxxxx> 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
.

Relevant Pages

  • Re: Structured exception information
    ... the programmers, I don't think that approach will produce good error ... involved in exception raising and exception handling in the ... But when the exceptions were reported as strings into some log ... program and can be arranged for Ada coverage rules. ...
    (comp.lang.ada)
  • Re: Ada exception block does NOT work?
    ... >> Ada has had exceptions, well integrated with the rest of the language, ... >> since Ada 80. ... What Ada calls "an exception" is what some other languages call "an ... declare an object of a task type, or create a heap object of a task type ...
    (comp.lang.ada)
  • Re: Extracting values from text file
    ... Mirco Wahab wrote: ... want numbers you must convert the strings. ... My other language of choice is Ada. ... Python in being a very strictly typed language. ...
    (comp.lang.python)
  • Re: No call for Ada (was Re: Announcing new scripting/prototyping
    ... :> have an Ada compiler check the completeness of messages. ... message, 50 language table, which is being done in Gnome and KDE. ... include translation memories and other useful things. ... necessary that perform table lookup using strings. ...
    (comp.lang.ada)
  • Re: Ada exception block does NOT work?
    ... then let's switch the context to other language that has no history issue like this. ... This gives the feeling that dealing with exceptions is something you just put in very special places, while in Ada you are more inclined to considering exceptions everywhere. ... should be associated to an exception. ... It could be the programmer's responsibility to store the context when an exception is raised, rather than propagating it with the exception. ...
    (comp.lang.ada)
Quantcast