Re: Operation can be dispatching in only one type

On Sat, 21 Nov 2009 00:02:59 -0600, Randy Brukardt wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:18wh86jvjvoe0.cofxcc8udm6q$.dlg@xxxxxxxxxxxxx
On Thu, 19 Nov 2009 17:54:40 -0600, Randy Brukardt wrote:
"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:1iipp3bn16fe2.yqa1gz1ru17a$.dlg@xxxxxxxxxxxxx
...
That might be true in general, but definitely not in this case: a handler
for Program_Error is *always* wrong (unless it is a global handler for *any*
exception), as Program_Error always represents a program bug. So I don't
see how "existing" handlers can be confused.

exception
when Error : others =>
some cleanup -- This usually becomes a problem
raise;

If that's the case, "some cleanup" is seriously flawed. An "others" handler
has to always work no matter what condition come into it, and in particular
cannot depend on the code/data it surrounds to be in any particular state.
The clean up code needs to be aware that data structures may be corrupt; if
it isn't it of course will cascade errors and generally make a mess -- but
in that case it is just junk code doing more harm than good.

Right, "others" stands for all "legal" exceptions propagating out of the
body, which the programmer was unable to specify, because it is too much
work to do. The problem is that "illegal" exceptions indicating broken
program do not belong here, and because of the lack of contracts you cannot
separate them. The pattern is wrong, but there is no other.

I believe this particular pattern ("others" handler containing explicit
cleanup) usually represents a bad design. Clients (or even the implementers
of ADTs) often forget to include the cleanup where it is needed. These days,
I try to put all needed cleanup into the ADTs, so that they get cleaned up
no matter what -- finalization is pretty much the only certainty in Ada. And
in that case, you don't need these kind of exception handlers.

I agree, but that only moves cleanup from one place to another (Finalize).
There is no way to get rid of it. Within Finalize cleanup has even more
chances to get perplexed, because in Ada you cannot know whether Finalize
was called upon normal leaving the scope due to an exception propagation.
Further the Ada's construction model is not enough fine to fully
accommodate this pattern.

For accessibility checks it could also aggravate the problem because
accessibility is not invariant to moving from one body to another. The same
code might be OK or not OK within different bodies.

And the huge log of messages doesn't matter, you only need the first one
(presuming every "others" handler logs the data).

No it will be the last one (it is a stack of errors which gets unwound),
but most likely it will be consumed by something else, like Program_Error.
That is a reason for the "wrong" pattern with "others". Yes it is bad, but
it lets you to log Exception_Information *before* things explode.

But of course the proper solution would be contracted exceptions.

I don't see how that would help. The problem is used "others" when you
really need to list the exceptions that you are expecting. If the compiler
is smart enough to be able to prove that no bounded errors occur (and no
constraint violations either), maybe that would do some good, but I doubt
that you will see such compilers anytime soon. In the absence of that, you
have to put Program_Error, Constraint_Error, and Storage_Error into every
contract, so you don't gain much.

It should be more intelligent than Java. For example, "I don't do
Storage_Error if there is N (static value) free bytes of stack", "I don't
raise Program_Error from Initialize/Finalize" etc.

An important issue to me is exception contract bound to some precondition,
which ensures absence of specified exceptions. When an exception happens,
it is not range error, or accessibility check to blame, but the
precondition violated.

The difference is that for string bound there is a way to do it safe and
for 'Access there is none (and I also agree with Robert's response.)

Well, Ada 2012 (or whatever it will be called) should help that out by
giving you a way to compare accessibilites (via memberships). So at least
you will be able to make checks to avoid the problem. Better than nothing,
but still not ideal. The better way to avoid the problem is to never, ever
use anonymous access types. (Named access types have checks that are always
made at compile-time for most compilers -- but not Janus/Ada, because of
generic sharing.)

The problem is not bound to only anonymous types. It also appears when you
convert access types. The source type (or both) might be a formal generic
parameter, so you cannot statically ensure that a "local" pointer is
converted no a "less local" one. Pool specific pointers need to be
converted though one target object is derived from another. Here everything
is broken: generic contract, meaningless conversion, meaningless check,
meaningless exception.

In this case, whether a check will fail is known statically for any compiler
that generates generics via macro substitution (that is all Ada compilers
other than Janus/Ada). I can hardly imagine that there exists a compiler
that will generate "raise Program_Error" unconditionally without generating
a warning!

Yes it generates that warning, and the warning is ignored. Any warning is
ignored, that is one the most fundamental principle of modern software
design. (:-))

The code was modified to X.all'Unchecked_Access. Everybody is happy?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: Returning external resources and Exceptions
    ... > when an exception is thrown. ... there remains the problem of code duplication. ... The same is true for most other cleanup methods in the API: ...
    (comp.lang.java.help)
  • Re: A "scopeguard" for Python
    ... Revert to the original state. ... For chdir(), it really doesn't matter. ... fails, and chdiris essentially atomic so if it raises an exception, ... cleanup can frequently be written to not care ...
    (comp.lang.python)
  • Re: A "scopeguard" for Python
    ... Do stuff requiring the modified state. ... Revert to the original state. ... fails, and chdiris essentially atomic so if it raises an exception, ... cleanup can frequently be written to not care ...
    (comp.lang.python)
  • Re: Why finally?
    ... other than organizational aesthetics ?? ... First of all, its not very common, or shouldn't be common to use catch all ... coders know that any cleanup will be within the finally block. ... An exception is raised in the catch block, finally will be executed, your ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: C++ in embedded systems
    ... linker and compiler work together flawlessly, ... when it has absolutely no idea what kind of exception handling ... programmer would imagine that the two calls to foowould take ... Providing an object constructor with a single parameter type may ...
    (comp.os.linux.embedded)