From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Operation can be dispatching in only one type
Date: Sat, 21 Nov 2009 00:02:59 -0600
Date: 2009-11-21T00:02:59-06:00 [thread overview]
Message-ID: <he7vql$c9p$1@munin.nbi.dk> (raw)
In-Reply-To: 18wh86jvjvoe0.cofxcc8udm6q$.dlg@40tude.net
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:18wh86jvjvoe0.cofxcc8udm6q$.dlg@40tude.net...
> On Thu, 19 Nov 2009 17:54:40 -0600, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1iipp3bn16fe2.yqa1gz1ru17a$.dlg@40tude.net...
...
>> 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.
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.
>> It is necessary to treat all Adjust and Finalize routines like task
>> bodies
>> in that they need a "when others" handler -- otherwise the exceptions are
>> sucked up and you get completely lost. Our programming standard requires
>> such handlers (generally, they output Exception_Information to the
>> logging
>> facility - and almost every significant Ada system needs some sort of
>> logging facility).
>
> Yes, but this does not help. Upon exception propagation
> (Constraint_Error),
> you get some objects finalized. This in turn causes a snowball of
> exceptions in finalized objects, because no design is robust to hold any
> error at any place. In the end you have a huge log of meaningless
> messages,
> which only complicate debugging.
That can happen, but it usually indicates too much coupling between objects
and/or too little concern about the implications of errors. Finalize
routines should never, ever propagate an exception, and need to be written
to avoid that - that means avoiding assumptions about other objects. If
that's not done, of course you get messy cascades of errors. I realize that
it isn't completely possible to avoid these things, but it can be minimized.
And the huge log of messages doesn't matter, you only need the first one
(presuming every "others" handler logs the data). That's the place the
exception was raised, and the information tells you how it got to that
point; just ignore the rest of the log (in that sense it is just like fixing
syntax errors in most compilers -- the correction isn't good enough to find
more than the first error if it is at all significant).
> Sometimes I which Ada had "halt at once"
> statement which would stop all tasks and hold any I/O.
Janus/Ada does have such a thing (always did, it was the first thing
implemented on CP/M back in 1980). It works because (to date) we don't use
operating systems facilities for tasking, exception handling, or
finalization. But it is pretty dangerous, and really can be used only to
instantly shut down a misbehaving system -- but of course if there is any
real resource management being handled by finalization, you could leak
resources such that you don't get them back easily (the obvious example is
temporary files, which won't be cleaned up in that scenario).
> 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.
>>> 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! So this is an academic concern at best (I don't think you're
using Janus/Ada) -- yes, you can ignore the warnings and run such a program,
but there isn't any reason to actually do so unless you're running an ACATS
test. (And if you do the conversion in the generic specification, the
compiler is required to reject the program.)
Randy.
next prev parent reply other threads:[~2009-11-21 6:02 UTC|newest]
Thread overview: 132+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-13 20:12 Operation can be dispatching in only one type xorque
2009-11-13 20:34 ` Dmitry A. Kazakov
2009-11-13 20:43 ` xorque
2009-11-13 21:14 ` Dmitry A. Kazakov
2009-11-13 20:44 ` xorque
2009-11-16 17:43 ` Adam Beneschan
2009-11-16 20:28 ` Dmitry A. Kazakov
2009-11-16 20:32 ` Dmitry A. Kazakov
2009-11-16 21:35 ` Adam Beneschan
2009-11-16 22:28 ` Dmitry A. Kazakov
2009-11-17 22:10 ` Adam Beneschan
2009-11-18 9:46 ` Dmitry A. Kazakov
2009-11-18 16:39 ` Adam Beneschan
2009-11-18 19:21 ` Dmitry A. Kazakov
2009-11-19 0:27 ` Randy Brukardt
2009-11-19 2:11 ` Robert A Duff
2009-11-19 15:57 ` Adam Beneschan
2009-11-19 19:39 ` Robert A Duff
2009-11-19 23:43 ` Randy Brukardt
2009-11-19 8:50 ` Dmitry A. Kazakov
2009-11-19 23:54 ` Randy Brukardt
2009-11-20 8:34 ` Dmitry A. Kazakov
2009-11-20 10:58 ` Jean-Pierre Rosen
2009-11-21 6:02 ` Randy Brukardt [this message]
2009-11-21 13:07 ` Dmitry A. Kazakov
2009-11-22 5:45 ` xorque
2009-11-22 11:25 ` Georg Bauhaus
2009-11-22 11:30 ` xorque
2009-11-22 16:25 ` Dmitry A. Kazakov
2009-11-22 16:27 ` xorque
2009-11-22 16:42 ` Dmitry A. Kazakov
2009-11-22 16:52 ` xorque
2009-11-22 17:41 ` Dmitry A. Kazakov
2009-11-22 18:03 ` xorque
2009-11-22 18:08 ` xorque
2009-11-22 18:28 ` Dmitry A. Kazakov
2009-11-22 18:41 ` xorque
2009-11-22 21:47 ` Robert A Duff
2009-11-23 3:42 ` stefan-lucks
2009-11-30 20:36 ` Robert A Duff
2009-11-30 23:54 ` (see below)
2009-12-01 12:13 ` Georg Bauhaus
2009-12-01 12:23 ` Georg Bauhaus
2009-12-01 12:44 ` Georg Bauhaus
2009-12-01 13:48 ` Dmitry A. Kazakov
2009-12-01 15:02 ` Georg Bauhaus
2009-12-01 16:18 ` Dmitry A. Kazakov
2009-12-01 17:52 ` Georg Bauhaus
2009-12-01 18:47 ` Dmitry A. Kazakov
2009-12-01 21:53 ` John B. Matthews
2009-12-02 0:32 ` Georg Bauhaus
2009-12-02 11:18 ` John B. Matthews
2009-12-02 14:29 ` Jean-Pierre Rosen
2009-12-02 15:35 ` Georg Bauhaus
2009-12-02 1:13 ` Georg Bauhaus
2009-12-02 9:07 ` Dmitry A. Kazakov
2009-12-02 12:35 ` John B. Matthews
2009-12-02 13:35 ` Dmitry A. Kazakov
2009-12-03 5:23 ` Randy Brukardt
2009-12-03 20:21 ` John B. Matthews
2009-12-03 5:29 ` Randy Brukardt
2009-12-03 11:24 ` Georg Bauhaus
2009-12-03 23:08 ` Randy Brukardt
2009-12-04 8:52 ` Dmitry A. Kazakov
2009-12-05 2:45 ` Randy Brukardt
2009-12-05 10:32 ` Dmitry A. Kazakov
2009-12-08 0:19 ` Randy Brukardt
2009-12-08 4:30 ` stefan-lucks
2009-12-08 9:12 ` Dmitry A. Kazakov
2009-12-10 4:09 ` Randy Brukardt
2009-12-11 0:10 ` Robert A Duff
2009-12-08 9:22 ` Dmitry A. Kazakov
2009-12-08 10:06 ` Georg Bauhaus
2009-12-08 10:23 ` Dmitry A. Kazakov
2009-12-08 10:33 ` Georg Bauhaus
2009-12-08 10:49 ` Dmitry A. Kazakov
2009-12-01 23:51 ` Randy Brukardt
2009-11-23 8:52 ` Dmitry A. Kazakov
2009-11-30 20:43 ` Robert A Duff
2009-12-01 9:00 ` Dmitry A. Kazakov
2009-12-01 5:45 ` stefan-lucks
2009-12-01 11:12 ` Dmitry A. Kazakov
2009-12-01 8:01 ` stefan-lucks
2009-12-01 13:37 ` Dmitry A. Kazakov
2009-12-15 23:54 ` Robert A Duff
2009-11-23 7:48 ` Georg Bauhaus
2009-11-23 7:58 ` Georg Bauhaus
2009-11-19 16:04 ` Adam Beneschan
2009-11-19 2:23 ` tmoran
2009-11-19 8:32 ` Dmitry A. Kazakov
-- strict thread matches above, loose matches on Subject: below --
2015-11-23 10:23 operation " Serge Robyns
2015-11-23 11:29 ` Dmitry A. Kazakov
2015-11-23 13:05 ` Serge Robyns
2015-11-23 13:48 ` Dmitry A. Kazakov
2015-11-23 14:16 ` Serge Robyns
2015-11-23 14:59 ` G.B.
2015-11-23 15:52 ` Dmitry A. Kazakov
2015-11-23 17:40 ` Jeffrey R. Carter
2015-11-24 9:08 ` Serge Robyns
2015-11-24 16:44 ` AdaMagica
2015-11-24 17:09 ` Jeffrey R. Carter
2015-11-24 18:37 ` Serge Robyns
2015-11-24 20:18 ` Jeffrey R. Carter
2015-11-24 20:40 ` Serge Robyns
2015-11-24 20:25 ` Niklas Holsti
2015-11-24 21:48 ` Jeffrey R. Carter
2015-11-25 8:24 ` Dmitry A. Kazakov
2015-11-25 11:22 ` Serge Robyns
2015-11-25 17:38 ` Dmitry A. Kazakov
2015-11-26 11:30 ` Serge Robyns
2015-11-26 13:14 ` Dmitry A. Kazakov
2015-11-26 14:27 ` Serge Robyns
2015-11-26 15:16 ` J-P. Rosen
2015-11-26 18:27 ` Serge Robyns
2015-11-26 21:20 ` J-P. Rosen
2015-11-27 8:37 ` Dmitry A. Kazakov
2015-11-27 12:58 ` J-P. Rosen
2015-11-27 13:39 ` Dmitry A. Kazakov
2015-11-30 22:22 ` Randy Brukardt
2015-12-01 8:46 ` Dmitry A. Kazakov
2015-12-01 11:19 ` G.B.
2015-12-01 13:56 ` Dmitry A. Kazakov
2015-12-01 16:05 ` G.B.
2015-12-01 17:58 ` Dmitry A. Kazakov
2015-12-02 13:06 ` G.B.
2015-12-02 13:31 ` Dmitry A. Kazakov
2015-12-02 19:33 ` Randy Brukardt
2015-12-02 19:27 ` Randy Brukardt
2015-11-29 17:59 ` Jacob Sparre Andersen
2015-11-30 22:29 ` Randy Brukardt
2015-11-25 12:27 ` G.B.
2015-11-25 17:25 ` Dmitry A. Kazakov
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox