* Exceptions @ 2007-12-06 15:00 shaunpatterson 2007-12-06 21:24 ` Exceptions tmoran ` (5 more replies) 0 siblings, 6 replies; 97+ messages in thread From: shaunpatterson @ 2007-12-06 15:00 UTC (permalink / raw) Is there any way to force programmers to catch exception that your function throws? Something like Java forcing coders to put try/catch blocks Thanks -- Shaun ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-06 15:00 Exceptions shaunpatterson @ 2007-12-06 21:24 ` tmoran 2007-12-07 8:54 ` Exceptions Dmitry A. Kazakov 2007-12-09 21:39 ` Exceptions Robert A Duff 2007-12-06 21:25 ` Exceptions Gautier ` (4 subsequent siblings) 5 siblings, 2 replies; 97+ messages in thread From: tmoran @ 2007-12-06 21:24 UTC (permalink / raw) >Is there any way to force programmers to catch exception that >your function throws? Do you mean force them to write code like: begin y := func(x); exception when funcs_important_exception=>null; -- ignore unimportant exception end; ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-06 21:24 ` Exceptions tmoran @ 2007-12-07 8:54 ` Dmitry A. Kazakov 2007-12-07 10:21 ` Exceptions Georg Bauhaus 2007-12-08 3:30 ` Exceptions Randy Brukardt 2007-12-09 21:39 ` Exceptions Robert A Duff 1 sibling, 2 replies; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-07 8:54 UTC (permalink / raw) On Thu, 06 Dec 2007 15:24:44 -0600, tmoran@acm.org wrote: >>Is there any way to force programmers to catch exception that >>your function throws? > Do you mean force them to write code like: > begin > y := func(x); > exception > when funcs_important_exception=>null; -- ignore unimportant exception > end; Semantics of exception handling is a different story. When a contract is satisfied, its implementation can still be incorrect. When "a way to force" reads "exceptions contract", then the answer is no, there is no way, alas. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-07 8:54 ` Exceptions Dmitry A. Kazakov @ 2007-12-07 10:21 ` Georg Bauhaus 2007-12-07 15:11 ` Exceptions shaunpatterson 2007-12-08 3:30 ` Exceptions Randy Brukardt 1 sibling, 1 reply; 97+ messages in thread From: Georg Bauhaus @ 2007-12-07 10:21 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Thu, 06 Dec 2007 15:24:44 -0600, tmoran@acm.org wrote: > >>> Is there any way to force programmers to catch exception that >>> your function throws? > >> Do you mean force them to write code like: >> begin >> y := func(x); >> exception >> when funcs_important_exception=>null; -- ignore unimportant exception >> end; > When "a way to force" reads "exceptions contract", then the answer is no, > there is no way, alas. > Nevertheless, the function can be declared in a package next to an exception declaration. This should, I think, alarm users of the package that the subprograms might raise an occurence. It should also point to who is responsible for catching. The exception's name can also be chosen to be more specific than Constraint_Error. Eiffel's way is to have names for pre- and post-conditions (etc.). The model is instructive, I think. feature {ANY} -- visible to any client func (x: INTEGER): INTEGER require even: x \\ 2 = 0 sizeable: x.abs > 2 do Result := raises_if_odd (x) -- o.K. Result := at_random(Result) -- might raise ensure -- Result is another integer provided some -- random number is good; -- otherwise, bad things might happen. end feature {NONE} -- fully private raises_if_odd(x: INTEGER): INTEGER -- assume x has been tested do Result := 42 // (x \\ 2 - 1) end g: RANDOM at_random(x: INTEGER): INTEGER -- try to produce another integer from `x` -- Forces a dangerous operation for this demo do g.forth Result := x // g.item -- deliberate danger! end ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-07 10:21 ` Exceptions Georg Bauhaus @ 2007-12-07 15:11 ` shaunpatterson 2007-12-07 16:08 ` Exceptions Gautier ` (2 more replies) 0 siblings, 3 replies; 97+ messages in thread From: shaunpatterson @ 2007-12-07 15:11 UTC (permalink / raw) Well that is unfortunate. I use exception handlers when appropriate... I cant say the same about the codemonkeys I work with. It'd be nice to force them to catch. Thanks ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-07 15:11 ` Exceptions shaunpatterson @ 2007-12-07 16:08 ` Gautier 2007-12-07 18:56 ` Exceptions Simon Wright 2007-12-08 10:04 ` Exceptions Stephen Leake 2 siblings, 0 replies; 97+ messages in thread From: Gautier @ 2007-12-07 16:08 UTC (permalink / raw) shaunpatterson@gmail.com wrote: > Well that is unfortunate. I use exception handlers when appropriate... > I cant say the same about the codemonkeys I work with. It'd be nice to force them to > catch. > > Thanks You can force them to pass their code through AdaControl, with a specific rule for that. It would also detect plenty of other mistakes of your monkeys... ______________________________________________________________ Gautier -- http://www.mysunrise.ch/users/gdm/index.htm Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm NB: For a direct answer, e-mail address on the Web site! ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-07 15:11 ` Exceptions shaunpatterson 2007-12-07 16:08 ` Exceptions Gautier @ 2007-12-07 18:56 ` Simon Wright 2007-12-08 10:04 ` Exceptions Stephen Leake 2 siblings, 0 replies; 97+ messages in thread From: Simon Wright @ 2007-12-07 18:56 UTC (permalink / raw) shaunpatterson@gmail.com writes: > Well that is unfortunate. I use exception handlers when > appropriate... I cant say the same about the codemonkeys I work > with. It'd be nice to force them to catch. Someone upthread pointed out that forcing people to catch will often mean that they just suppress the exception, usually with disastrous results. I'd rather let unexpected exceptions propagate to some outer wrapper. The comment accompanying the subprogram spec should say 'may raise ...'. I've suggested in the past that a package/suite should only deliberately propagate exceptions that make sense in the context of the package/suite -- in other words, don't propagate GNAT.Sockets.Socket_Error if you're a web client and what you mean is that you've lost connection with a server. I'm not so sure about this now, because it makes it very awkward to debug (we usually just get the traceback, core dumps tricky on the target board). What I'd like is to be able to propagate my exception with the original callback info -- very compiler-specific, I would think. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-07 15:11 ` Exceptions shaunpatterson 2007-12-07 16:08 ` Exceptions Gautier 2007-12-07 18:56 ` Exceptions Simon Wright @ 2007-12-08 10:04 ` Stephen Leake 2 siblings, 0 replies; 97+ messages in thread From: Stephen Leake @ 2007-12-08 10:04 UTC (permalink / raw) shaunpatterson@gmail.com writes: > Well that is unfortunate. I use exception handlers when appropriate... > I cant say the > same about the codemonkeys I work with. It'd be nice to force them to > catch. That's up to the project managers; coding style is enforced by code reviews. -- -- Stephe ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-07 8:54 ` Exceptions Dmitry A. Kazakov 2007-12-07 10:21 ` Exceptions Georg Bauhaus @ 2007-12-08 3:30 ` Randy Brukardt 2007-12-08 10:09 ` Contracted exceptions for Ada (was: Exceptions) Dmitry A. Kazakov 2007-12-08 12:26 ` Exceptions Peter C. Chapin 1 sibling, 2 replies; 97+ messages in thread From: Randy Brukardt @ 2007-12-08 3:30 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:uvkiadiwrfh2.wi288ebeq18y.dlg@40tude.net... ... > When "a way to force" reads "exceptions contract", then the answer is no, > there is no way, alas. The ARG has discussed "exception contracts" a couple of times, but there didn't seem that there was enough interest. The problem was mainly that they simply don't look very valuable (for Ada, I'm not going to comment on other languages) when the details are looked at, and they'd be fairly complex to define. The biggest issue is compatibility, of course (since Ada has had exceptions from the beginning, and never has had contracts, they'd have to be optional - but it's not clear if optional contracts are worth much). Another one is what to do if a contract is violated. The obvious answer of raising Program_Error doesn't do anything other than lose information about an exception, so that isn't very satisfying. (Static detection of contract violations isn't possible in general because the contracts have to be optional.) And then there is the problem of predefined exceptions like Storage_Error -- every routine *can* raise Storage_Error, although few *expect* to do so (if they don't allocate memory). Does that have to be included in every contract? If so, that's ugly, and if not, the oddity of not quite a contract is unpleasant. And there are more issues: the maintenance cascade when an exception is added or removed; what about call-back routines (think Process in the Containers library); and so on. I'm sure that something could be worked out, but it seemed like there were more valuable things to do. Randy. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Contracted exceptions for Ada (was: Exceptions) 2007-12-08 3:30 ` Exceptions Randy Brukardt @ 2007-12-08 10:09 ` Dmitry A. Kazakov 2007-12-09 10:22 ` Contracted exceptions for Ada Stephen Leake ` (3 more replies) 2007-12-08 12:26 ` Exceptions Peter C. Chapin 1 sibling, 4 replies; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-08 10:09 UTC (permalink / raw) On Fri, 7 Dec 2007 21:30:05 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:uvkiadiwrfh2.wi288ebeq18y.dlg@40tude.net... > ... >> When "a way to force" reads "exceptions contract", then the answer is no, >> there is no way, alas. > > The ARG has discussed "exception contracts" a couple of times, but there > didn't seem that there was enough interest. The problem was mainly that they > simply don't look very valuable My observation is that a big deal of debugging Ada code is about tracing down unexpected exceptions. I cannot give any figures, but it is extremely frequent that a bug manifests itself as an exception propagation. Typically Constraint_Error propagates where you didn't expect it. So the temptation is to catch most of such things at compile time. (Maybe a wild guess, but this could save Ariane V. A program assumed Constraint_Error exception free was recompiled for the hardware where that was not the case.) > (for Ada, I'm not going to comment on other > languages) when the details are looked at, and they'd be fairly complex to > define. The biggest issue is compatibility, of course (since Ada has had > exceptions from the beginning, and never has had contracts, they'd have to > be optional - but it's not clear if optional contracts are worth much). I don't see a problem here. Legacy code will have an implied exception contract stating that anything may propagate out. > Another one is what to do if a contract is violated. The obvious answer of > raising Program_Error doesn't do anything other than lose information about > an exception, so that isn't very satisfying. Yes, in my view exception contracts have to be static. (It makes no sense to have run-time exception contracts. As well as any other contracts, there is no any authority body to judge contract violations at run-time.) > (Static detection of contract > violations isn't possible in general because the contracts have to be > optional.) It is not optional it is "any exception may propagate." > And then there is the problem of predefined exceptions like > Storage_Error -- every routine *can* raise Storage_Error, although few > *expect* to do so (if they don't allocate memory). Does that have to be > included in every contract? That's up to the programmer's choice. If he chooses to contract Storage_Error as non-propagating, then be it so. I think there exist ways to provide much better control over Storage_Error than we have and without distributed overhead. The contract on Storage_Error would be conditional. That is - the subroutine Foo does not raise Storage_Error if there is N1..Nn bytes of free space in the storage pools P1..Pn. Such contracts are conservatively checkable. Of course, the actual pool states themselves will never be checked at run-time (following the principle above). In extraordinary cases the programmer should have a option to give his word that a subprogram or a part of require no more than N bytes. That would be an "unchecked Storage_Error contract", by analogy to Unchecked_Conversion: function Recursive (...) return ... is -- I give my word that Recursive uses only 10K of stack begin if ... then return Recursive (...); else return ...; end if; end Recursive; > If so, that's ugly, and if not, the oddity of > not quite a contract is unpleasant. And there are more issues: the > maintenance cascade when an exception is added or removed; No problem. Exception contracts should be inheritable. File open would say "I raise this and that and also anything disk driver does." (I remember Robert Duff proposed that once.) > what about > call-back routines (think Process in the Containers library); and so on. Conditional contracts: container's Forall is exception E free if Process is. > I'm sure that something could be worked out, but it seemed like there were > more valuable things to do. Like multiple dispatch? (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-08 10:09 ` Contracted exceptions for Ada (was: Exceptions) Dmitry A. Kazakov @ 2007-12-09 10:22 ` Stephen Leake 2007-12-09 11:02 ` Dmitry A. Kazakov 2007-12-09 15:11 ` Contracted exceptions for Ada (was: Exceptions) Martin Krischik ` (2 subsequent siblings) 3 siblings, 1 reply; 97+ messages in thread From: Stephen Leake @ 2007-12-09 10:22 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Fri, 7 Dec 2007 21:30:05 -0600, Randy Brukardt wrote: > >> Another one is what to do if a contract is violated. The obvious answer of >> raising Program_Error doesn't do anything other than lose information about >> an exception, so that isn't very satisfying. > > Yes, in my view exception contracts have to be static. The only way to statically enforce exception contracts is to use SPARK Ada (http://www.praxis-his.com/sparkada/). SPARK Ada does do exactly that (among other things); it also signficantly restricts the Ada language to a manageable subset. So if you like exception contracts, use SPARK Ada. If you like all the things SPARK Ada leaves out (I don't have the current list handy; it doesn't seem to be on the web site), use standard Ada. -- -- Stephe ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-09 10:22 ` Contracted exceptions for Ada Stephen Leake @ 2007-12-09 11:02 ` Dmitry A. Kazakov 2007-12-11 8:10 ` Stephen Leake 0 siblings, 1 reply; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-09 11:02 UTC (permalink / raw) On Sun, 09 Dec 2007 05:22:44 -0500, Stephen Leake wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On Fri, 7 Dec 2007 21:30:05 -0600, Randy Brukardt wrote: >> >>> Another one is what to do if a contract is violated. The obvious answer of >>> raising Program_Error doesn't do anything other than lose information about >>> an exception, so that isn't very satisfying. >> >> Yes, in my view exception contracts have to be static. > > The only way to statically enforce exception contracts is to use SPARK > Ada (http://www.praxis-his.com/sparkada/). SPARK Ada does do exactly > that (among other things); it also signficantly restricts the Ada > language to a manageable subset. (I doubt that limitations of SPARK are caused by contracted exceptions. It just does right what Ada didn't.) > So if you like exception contracts, use SPARK Ada. > > If you like all the things SPARK Ada leaves out (I don't have the > current list handy; it doesn't seem to be on the web site), use > standard Ada. This does not answer the questions, which are two: 1. Are contracted exceptions any good? (If they are not then SPARK isn't as well) 2. Can Ada have them? (If not then why SPARK does?) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-09 11:02 ` Dmitry A. Kazakov @ 2007-12-11 8:10 ` Stephen Leake 2007-12-11 10:36 ` Dmitry A. Kazakov 0 siblings, 1 reply; 97+ messages in thread From: Stephen Leake @ 2007-12-11 8:10 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Sun, 09 Dec 2007 05:22:44 -0500, Stephen Leake wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >> >>> On Fri, 7 Dec 2007 21:30:05 -0600, Randy Brukardt wrote: >>> >>>> Another one is what to do if a contract is violated. The obvious answer of >>>> raising Program_Error doesn't do anything other than lose information about >>>> an exception, so that isn't very satisfying. >>> >>> Yes, in my view exception contracts have to be static. >> >> The only way to statically enforce exception contracts is to use SPARK >> Ada (http://www.praxis-his.com/sparkada/). SPARK Ada does do exactly >> that (among other things); it also signficantly restricts the Ada >> language to a manageable subset. > > (I doubt that limitations of SPARK are caused by contracted exceptions. Correct. The limitations are introduced to make static analysis tractable with the current state of the art. > It just does right what Ada didn't. I wouldn't go that far. As time goes on, more of Ada is permitted in Spark, because the static analysis technology, and the computers it runs on, gets better. >> So if you like exception contracts, use SPARK Ada. >> >> If you like all the things SPARK Ada leaves out (I don't have the >> current list handy; it doesn't seem to be on the web site), use >> standard Ada. > > This does not answer the questions, which are two: > > 1. Are contracted exceptions any good? Yes, for high integrity systems. > 2. Can Ada have them? No, because it is too hard to do the static analysis to enforce the contracts. -- -- Stephe ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-11 8:10 ` Stephen Leake @ 2007-12-11 10:36 ` Dmitry A. Kazakov 0 siblings, 0 replies; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-11 10:36 UTC (permalink / raw) On Tue, 11 Dec 2007 03:10:36 -0500, Stephen Leake wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> 2. Can Ada have them? > > No, because it is too hard to do the static analysis to enforce the contracts. It is a misunderstanding, I addressed this question in my answer to Randy. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada (was: Exceptions) 2007-12-08 10:09 ` Contracted exceptions for Ada (was: Exceptions) Dmitry A. Kazakov 2007-12-09 10:22 ` Contracted exceptions for Ada Stephen Leake @ 2007-12-09 15:11 ` Martin Krischik 2007-12-09 17:36 ` Contracted exceptions for Ada Dmitry A. Kazakov 2007-12-09 22:09 ` Robert A Duff 2007-12-11 1:53 ` Contracted exceptions for Ada (was: Exceptions) Randy Brukardt 3 siblings, 1 reply; 97+ messages in thread From: Martin Krischik @ 2007-12-09 15:11 UTC (permalink / raw) Dmitry A. Kazakov wrote: > (Maybe a wild guess, but this could save Ariane V. A program assumed > Constraint_Error exception free was recompiled for the hardware where that > was not the case.) My understanding is that the system was brought down by an unexpected hardware exception - i.E. one which the CPU's floating point unit generated. See: http://en.wikipedia.org/wiki/Ariane_5#Launch_history Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-09 15:11 ` Contracted exceptions for Ada (was: Exceptions) Martin Krischik @ 2007-12-09 17:36 ` Dmitry A. Kazakov 2007-12-09 18:39 ` Simon Wright 2007-12-09 19:04 ` Martin Krischik 0 siblings, 2 replies; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-09 17:36 UTC (permalink / raw) On Sun, 09 Dec 2007 16:11:13 +0100, Martin Krischik wrote: > Dmitry A. Kazakov wrote: > >> (Maybe a wild guess, but this could save Ariane V. A program assumed >> Constraint_Error exception free was recompiled for the hardware where that >> was not the case.) > > My understanding is that the system was brought down by an unexpected > hardware exception - i.E. one which the CPU's floating point unit > generated. Yes, and that would be detected by the compiler: function Integer (X : Float) return Integer; which was contracted as exception-free on one platform will not be on another. So the compiler would reject either its implementation that raises Constraint_Error or else its use contracted as Constraint_Error-free. So the idea. (Contracted exceptions would mean a damn LOT of work for the compiler vendors.) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-09 17:36 ` Contracted exceptions for Ada Dmitry A. Kazakov @ 2007-12-09 18:39 ` Simon Wright 2007-12-10 8:19 ` Dmitry A. Kazakov 2007-12-09 19:04 ` Martin Krischik 1 sibling, 1 reply; 97+ messages in thread From: Simon Wright @ 2007-12-09 18:39 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Sun, 09 Dec 2007 16:11:13 +0100, Martin Krischik wrote: > >> Dmitry A. Kazakov wrote: >> >>> (Maybe a wild guess, but this could save Ariane V. A program assumed >>> Constraint_Error exception free was recompiled for the hardware where that >>> was not the case.) >> >> My understanding is that the system was brought down by an unexpected >> hardware exception - i.E. one which the CPU's floating point unit >> generated. > > Yes, and that would be detected by the compiler: > > function Integer (X : Float) return Integer; > > which was contracted as exception-free on one platform will not be on > another. So the compiler would reject either its implementation that raises > Constraint_Error or else its use contracted as Constraint_Error-free. So > the idea. I don't see how the compiler/platform in use has anything to do with this. In Ariane IV the maximum horizontal velocity is X. Therefore we can convert the hardware input to this-type without worrying about overflow. Therefore any exception will be caused by hardware error. seems a proper analysis for Ariane IV; reusing precisely the same software/platform in an environment where the maximum horizontal velocity was much larger than X is an error that no amount of *software* engineering is going to fix. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-09 18:39 ` Simon Wright @ 2007-12-10 8:19 ` Dmitry A. Kazakov 2007-12-10 20:25 ` Simon Wright 0 siblings, 1 reply; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-10 8:19 UTC (permalink / raw) On Sun, 09 Dec 2007 18:39:31 +0000, Simon Wright wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On Sun, 09 Dec 2007 16:11:13 +0100, Martin Krischik wrote: >> >>> Dmitry A. Kazakov wrote: >>> >>>> (Maybe a wild guess, but this could save Ariane V. A program assumed >>>> Constraint_Error exception free was recompiled for the hardware where that >>>> was not the case.) >>> >>> My understanding is that the system was brought down by an unexpected >>> hardware exception - i.E. one which the CPU's floating point unit >>> generated. >> >> Yes, and that would be detected by the compiler: >> >> function Integer (X : Float) return Integer; >> >> which was contracted as exception-free on one platform will not be on >> another. So the compiler would reject either its implementation that raises >> Constraint_Error or else its use contracted as Constraint_Error-free. So >> the idea. > > I don't see how the compiler/platform in use has anything to do with > this. > > In Ariane IV the maximum horizontal velocity is X. > > Therefore we can convert the hardware input to this-type without > worrying about overflow. Hardware input had a type different from one used later in the control circle, because it needed to be converted. So what was the contract of that conversion? > Therefore any exception will be caused by hardware error. The article mentioned by Martin talks about floating point to integer conversion. Was the conversion programmed in Ada? Probably it wasn't. Then I can only wonder why people keep on talking about "Ada fault"... > seems a proper analysis for Ariane IV; reusing precisely the same > software/platform in an environment where the maximum horizontal > velocity was much larger than X is an error that no amount of > *software* engineering is going to fix. My point is that the fault could be detected (assuming that conversion was in Ada), under the condition that the compiler vendor would not make the same mistake while porting the compiler... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-10 8:19 ` Dmitry A. Kazakov @ 2007-12-10 20:25 ` Simon Wright 2007-12-11 8:50 ` Dmitry A. Kazakov 0 siblings, 1 reply; 97+ messages in thread From: Simon Wright @ 2007-12-10 20:25 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Sun, 09 Dec 2007 18:39:31 +0000, Simon Wright wrote: >> In Ariane IV the maximum horizontal velocity is X. >> >> Therefore we can convert the hardware input to this-type without >> worrying about overflow. > > Hardware input had a type different from one used later in the > control circle, because it needed to be converted. So what was the > contract of that conversion? The Ariane IV system engineers said to themselves, and probably in the design documentation, "The maximum horizontal velocity is X. Therefore the conversion to the fixed-point type _Whatever_ cannot overflow. Therefore we do not need to handle exceptions for this conversion, so (given we are short of CPU power) we will not do any extra processing to avoid exceptions." Not sure they would have recognised "contract" in that context. > My point is that the fault could be detected (assuming that > conversion was in Ada), under the condition that the compiler vendor > would not make the same mistake while porting the compiler... (:-)) Not if there was no port, and the exact same hardware with the exact same software was reused! (I'm not sure if that was in fact the case) ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-10 20:25 ` Simon Wright @ 2007-12-11 8:50 ` Dmitry A. Kazakov 2007-12-11 20:50 ` Simon Wright 0 siblings, 1 reply; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-11 8:50 UTC (permalink / raw) On Mon, 10 Dec 2007 20:25:34 +0000, Simon Wright wrote: > The Ariane IV system engineers said to themselves, and probably in the > design documentation, "The maximum horizontal velocity is X. Therefore > the conversion to the fixed-point type _Whatever_ cannot > overflow. Therefore we do not need to handle exceptions for this > conversion, so (given we are short of CPU power) we will not do any > extra processing to avoid exceptions." > > Not sure they would have recognised "contract" in that context. Yes, my premise was that the type of H_Input changed from Ariane IV to Ariane V. In this case translation of the conversion function H_Input_To_Whatever could refute the second "therefore" because X would not be the maximal possible value of H_Input anymore. >> My point is that the fault could be detected (assuming that >> conversion was in Ada), under the condition that the compiler vendor >> would not make the same mistake while porting the compiler... (:-)) > > Not if there was no port, and the exact same hardware with the exact > same software was reused! (I'm not sure if that was in fact the case) You mean that the ADC was reused as well? In that case (just speculating of course) the compiler could detect the problem already for Ariane IV, noticing that the range of H_Input is not bound by X and forcing to add an exception handler somewhere. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-11 8:50 ` Dmitry A. Kazakov @ 2007-12-11 20:50 ` Simon Wright 2007-12-12 10:20 ` Dmitry A. Kazakov 0 siblings, 1 reply; 97+ messages in thread From: Simon Wright @ 2007-12-11 20:50 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Mon, 10 Dec 2007 20:25:34 +0000, Simon Wright wrote: > >> The Ariane IV system engineers said to themselves, and probably in >> the design documentation, "The maximum horizontal velocity is >> X. Therefore the conversion to the fixed-point type _Whatever_ >> cannot overflow. Therefore we do not need to handle exceptions for >> this conversion, so (given we are short of CPU power) we will not >> do any extra processing to avoid exceptions." >> >> Not sure they would have recognised "contract" in that context. > > Yes, my premise was that the type of H_Input changed from Ariane IV > to Ariane V. In this case translation of the conversion function > H_Input_To_Whatever could refute the second "therefore" because X > would not be the maximal possible value of H_Input anymore. X was *never* the maximum possible value of H_Input! ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-11 20:50 ` Simon Wright @ 2007-12-12 10:20 ` Dmitry A. Kazakov 0 siblings, 0 replies; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-12 10:20 UTC (permalink / raw) On Tue, 11 Dec 2007 20:50:07 +0000, Simon Wright wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On Mon, 10 Dec 2007 20:25:34 +0000, Simon Wright wrote: >> >>> The Ariane IV system engineers said to themselves, and probably in >>> the design documentation, "The maximum horizontal velocity is >>> X. Therefore the conversion to the fixed-point type _Whatever_ >>> cannot overflow. Therefore we do not need to handle exceptions for >>> this conversion, so (given we are short of CPU power) we will not >>> do any extra processing to avoid exceptions." >>> >>> Not sure they would have recognised "contract" in that context. >> >> Yes, my premise was that the type of H_Input changed from Ariane IV >> to Ariane V. In this case translation of the conversion function >> H_Input_To_Whatever could refute the second "therefore" because X >> would not be the maximal possible value of H_Input anymore. > > X was *never* the maximum possible value of H_Input! In that case with contracted exceptions, the code without an exception handler were illegal from the beginning. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-09 17:36 ` Contracted exceptions for Ada Dmitry A. Kazakov 2007-12-09 18:39 ` Simon Wright @ 2007-12-09 19:04 ` Martin Krischik 2007-12-10 8:20 ` Dmitry A. Kazakov 1 sibling, 1 reply; 97+ messages in thread From: Martin Krischik @ 2007-12-09 19:04 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Sun, 09 Dec 2007 16:11:13 +0100, Martin Krischik wrote: > >> Dmitry A. Kazakov wrote: >> >>> (Maybe a wild guess, but this could save Ariane V. A program assumed >>> Constraint_Error exception free was recompiled for the hardware where >>> that was not the case.) >> >> My understanding is that the system was brought down by an unexpected >> hardware exception - i.E. one which the CPU's floating point unit >> generated. > > Yes, and that would be detected by the compiler: > > function Integer (X : Float) return Integer; > > which was contracted as exception-free on one platform will not be on > another. So the compiler would reject either its implementation that > raises Constraint_Error or else its use contracted as > Constraint_Error-free. So the idea. > > (Contracted exceptions would mean a damn LOT of work for the compiler > vendors.) I forgot to mention mentioned that they used pragma Suppress to speed thing up (the old 'pedia article mentioned that). With pragma Suppress in place the HW-exception was never converted into an Ada-exception. Even the best exception handling won't help if you switch it off :-( . Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-09 19:04 ` Martin Krischik @ 2007-12-10 8:20 ` Dmitry A. Kazakov 0 siblings, 0 replies; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-10 8:20 UTC (permalink / raw) On Sun, 09 Dec 2007 20:04:44 +0100, Martin Krischik wrote: > Dmitry A. Kazakov wrote: > >> On Sun, 09 Dec 2007 16:11:13 +0100, Martin Krischik wrote: >> >>> Dmitry A. Kazakov wrote: >>> >>>> (Maybe a wild guess, but this could save Ariane V. A program assumed >>>> Constraint_Error exception free was recompiled for the hardware where >>>> that was not the case.) >>> >>> My understanding is that the system was brought down by an unexpected >>> hardware exception - i.E. one which the CPU's floating point unit >>> generated. >> >> Yes, and that would be detected by the compiler: >> >> function Integer (X : Float) return Integer; >> >> which was contracted as exception-free on one platform will not be on >> another. So the compiler would reject either its implementation that >> raises Constraint_Error or else its use contracted as >> Constraint_Error-free. So the idea. >> >> (Contracted exceptions would mean a damn LOT of work for the compiler >> vendors.) > > I forgot to mention mentioned that they used pragma Suppress to speed thing > up (the old 'pedia article mentioned that). With pragma Suppress in place > the HW-exception was never converted into an Ada-exception. > > Even the best exception handling won't help if you switch it off :-( . See, but you could not switch off the language! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-08 10:09 ` Contracted exceptions for Ada (was: Exceptions) Dmitry A. Kazakov 2007-12-09 10:22 ` Contracted exceptions for Ada Stephen Leake 2007-12-09 15:11 ` Contracted exceptions for Ada (was: Exceptions) Martin Krischik @ 2007-12-09 22:09 ` Robert A Duff 2007-12-10 7:09 ` Stefan Lucks 2007-12-11 1:53 ` Contracted exceptions for Ada (was: Exceptions) Randy Brukardt 3 siblings, 1 reply; 97+ messages in thread From: Robert A Duff @ 2007-12-09 22:09 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > No problem. Exception contracts should be inheritable. File open would say > "I raise this and that and also anything disk driver does." (I remember > Robert Duff proposed that once.) I think what I proposed was more like what you say below: >> what about >> call-back routines (think Process in the Containers library); and so on. > > Conditional contracts: container's Forall is exception E free if Process > is. Right -- an iterator needs to be able to say "I can raise anything raised by the loop-body procedure that is passed in to me." That's one thing missing from Java, which makes exception contracts more painful than they need to be. Passing a procedure to an iterator causes the compiler to lose useful information. I think preconditions could help a lot in this general area -- instead of saying "I might raise Divide_By_Zero" on the divide procedure, one can specify exactly what circumstances cause that exception -- Divide_By_Zero will be raised if and only if you try to divide by zero. Then if at the call site, you divide by X, and X is Positive, there's no need for a handler. Unfortunately, there's no Non_Zero subtype. - Bob ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-09 22:09 ` Robert A Duff @ 2007-12-10 7:09 ` Stefan Lucks 2007-12-10 16:57 ` Robert A Duff 0 siblings, 1 reply; 97+ messages in thread From: Stefan Lucks @ 2007-12-10 7:09 UTC (permalink / raw) > no need for a handler. Unfortunately, there's no Non_Zero subtype. I am afraid, a non-zero subtype would move the problem around, rather than solve it. The exception not raised by X/Y might then be raised before, when you compute Y:=A-B. On a second look, this might actually be useful better diagnostics. The exception is raised closer to the point where the faulty value (the zero Y) is created, rather than, perhaps, much later. So long -- Stefan Lucks (moved to Bauhaus-University Weimar, Germany) <Stefan.Lucks at medien.uni-weimar.de> ------ I love the taste of Cryptanalysis in the morning! ------ ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-10 7:09 ` Stefan Lucks @ 2007-12-10 16:57 ` Robert A Duff 0 siblings, 0 replies; 97+ messages in thread From: Robert A Duff @ 2007-12-10 16:57 UTC (permalink / raw) Stefan Lucks <lucks@th.informatik.uni-mannheim.de> writes: >> no need for a handler. Unfortunately, there's no Non_Zero subtype. > > I am afraid, a non-zero subtype would move the problem around, rather > than solve it. The exception not raised by X/Y might then be raised > before, when you compute Y:=A-B. > > On a second look, this might actually be useful better diagnostics. The > exception is raised closer to the point where the faulty value (the zero > Y) is created, rather than, perhaps, much later. Exactly. Pushing the check to the caller makes it more likely that you can prove it's true statically. E.g. suppose you read a number from the keyboard, and pass it around, store it in a data structure, retrieve it from the data structure, and then divide by it. The "read" part should do input validation, or else there's a bug. If all the subtypes of those parameters and data structures had a "cannot equal zero" invariant, then the bug is isolated to the "read" part. And if that part says "if Value /= 0 ..." then it's easy to prove that the bug is not there. - Bob ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada (was: Exceptions) 2007-12-08 10:09 ` Contracted exceptions for Ada (was: Exceptions) Dmitry A. Kazakov ` (2 preceding siblings ...) 2007-12-09 22:09 ` Robert A Duff @ 2007-12-11 1:53 ` Randy Brukardt 2007-12-11 9:16 ` Contracted exceptions for Ada Dmitry A. Kazakov 3 siblings, 1 reply; 97+ messages in thread From: Randy Brukardt @ 2007-12-11 1:53 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:7m9wkymyi5h7.1235e72is9mp9.dlg@40tude.net... > On Fri, 7 Dec 2007 21:30:05 -0600, Randy Brukardt wrote: ... > > The ARG has discussed "exception contracts" a couple of times, but there > > didn't seem that there was enough interest. The problem was mainly that they > > simply don't look very valuable > > My observation is that a big deal of debugging Ada code is about tracing > down unexpected exceptions. I cannot give any figures, but it is extremely > frequent that a bug manifests itself as an exception propagation. Typically > Constraint_Error propagates where you didn't expect it. So the temptation > is to catch most of such things at compile time. That's not going to be useful, since virtually any code that you can write *might* raise Constraint_Error, and a lot of code *could* raise Program_Error, and everything *could* raise Storage_Error. There is no way to write a contract that doesn't contain those exceptions. ... > > Another one is what to do if a contract is violated. The obvious answer of > > raising Program_Error doesn't do anything other than lose information about > > an exception, so that isn't very satisfying. > > Yes, in my view exception contracts have to be static. (It makes no sense > to have run-time exception contracts. As well as any other contracts, there > is no any authority body to judge contract violations at run-time.) OK, but that isn't going to happen in Ada. What you are looking for is a static analysis tool, like SPARK. That's especially true as you'll need static preconditions to have any hope of eliminating the Constraint_Errors (subtypes aren't powerful enough). It is highly unlikely that the language is going to go in that direction; the language has been very careful to avoid requiring analysis beyond that of a single expression, and trying to get vendors to re-architect their compilers is probably a good way to cut the number of Ada implementations to zero. Randy. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-11 1:53 ` Contracted exceptions for Ada (was: Exceptions) Randy Brukardt @ 2007-12-11 9:16 ` Dmitry A. Kazakov 2007-12-12 0:26 ` Randy Brukardt 0 siblings, 1 reply; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-11 9:16 UTC (permalink / raw) On Mon, 10 Dec 2007 19:53:27 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:7m9wkymyi5h7.1235e72is9mp9.dlg@40tude.net... >> On Fri, 7 Dec 2007 21:30:05 -0600, Randy Brukardt wrote: > ... >>> The ARG has discussed "exception contracts" a couple of times, but there >>> didn't seem that there was enough interest. The problem was mainly that they >>> simply don't look very valuable >> >> My observation is that a big deal of debugging Ada code is about tracing >> down unexpected exceptions. I cannot give any figures, but it is extremely >> frequent that a bug manifests itself as an exception propagation. Typically >> Constraint_Error propagates where you didn't expect it. So the temptation >> is to catch most of such things at compile time. > > That's not going to be useful, since virtually any code that you can write > *might* raise Constraint_Error, Why is it a problem? > and a lot of code *could* raise > Program_Error, and everything *could* raise Storage_Error. There is no way > to write a contract that doesn't contain those exceptions. Program_Error is not my concern. Storage_Error can be fixed as I described earlier. And for all, what I meant under exception contracts was not about making a program exception-free. It was about specifying which exception can propagate and which cannot. >>> Another one is what to do if a contract is violated. The obvious answer of >>> raising Program_Error doesn't do anything other than lose information about >>> an exception, so that isn't very satisfying. >> >> Yes, in my view exception contracts have to be static. (It makes no sense >> to have run-time exception contracts. As well as any other contracts, there >> is no any authority body to judge contract violations at run-time.) > > OK, but that isn't going to happen in Ada. What you are looking for is a > static analysis tool, like SPARK. That's especially true as you'll need > static preconditions to have any hope of eliminating the Constraint_Errors > (subtypes aren't powerful enough). This is a separate issue. You seem to imply that the exception contracts shall specify *when* an exception is raised or not. That is a much harder problem and it indeed would require pre- and postconditions and cannot be done in general case. What I am talking about is a much weaker framework which only proves whether an exception cannot propagate. We do not need pre-/postconditions for that. A comparable case is exact real vs. interval arithmetic. We don't need exact exception propagation analysis, we do a conservative *estimation* of. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Contracted exceptions for Ada 2007-12-11 9:16 ` Contracted exceptions for Ada Dmitry A. Kazakov @ 2007-12-12 0:26 ` Randy Brukardt 0 siblings, 0 replies; 97+ messages in thread From: Randy Brukardt @ 2007-12-12 0:26 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:185k0c8e598ko.16o5j2iv35zpn$.dlg@40tude.net... > On Mon, 10 Dec 2007 19:53:27 -0600, Randy Brukardt wrote: ... > > That's not going to be useful, since virtually any code that you can write > > *might* raise Constraint_Error, > > Why is it a problem? Because every contract would have to include Constraint_Error, and that would add a huge amount of verbiage to programs for no benefit. Or you have to exclude it from the contract like Java does, which would be worse. > > and a lot of code *could* raise > > Program_Error, and everything *could* raise Storage_Error. There is no way > > to write a contract that doesn't contain those exceptions. > > Program_Error is not my concern. Storage_Error can be fixed as I described > earlier. Program_Error *is* your concern. There is no way that a compiler could prove that it would not be raised from a lot of code; as such it would have to be included in the contract even though it isn't interesting to anyone (presuming again static contract checking and no "unchecked" exceptions). And your solution for Storage_Error adds a large number of new rules to the language, and is unlikely to make it possible to eliminate the exception. For instance, other tasks can allocate memory for the heap, so the only possible way to tell if you are out of heap memory is to catch the exception -- anything else is a race. And Janus/Ada at least uses heap memory to allocate virtually everything not statically sized: pretty much anything other than an elementary object or "null;" can raise Storage_Error in Janus/Ada. Besides, you say you don't want to add preconditions and the like, and then you do exactly that to handle Storage_Error. Can't have it both ways... > And for all, what I meant under exception contracts was not about making a > program exception-free. It was about specifying which exception can > propagate and which cannot. Right, but the predefined exceptions can always propagate. The only way to prove that they don't is to do extensive static analysis, and that isn't happening in the language. > >>> Another one is what to do if a contract is violated. The obvious answer of > >>> raising Program_Error doesn't do anything other than lose information about > >>> an exception, so that isn't very satisfying. > >> > >> Yes, in my view exception contracts have to be static. (It makes no sense > >> to have run-time exception contracts. As well as any other contracts, there > >> is no any authority body to judge contract violations at run-time.) > > > > OK, but that isn't going to happen in Ada. What you are looking for is a > > static analysis tool, like SPARK. That's especially true as you'll need > > static preconditions to have any hope of eliminating the Constraint_Errors > > (subtypes aren't powerful enough). > > This is a separate issue. You seem to imply that the exception contracts > shall specify *when* an exception is raised or not. That is a much harder > problem and it indeed would require pre- and postconditions and cannot be > done in general case. What I am talking about is a much weaker framework > which only proves whether an exception cannot propagate. We do not need > pre-/postconditions for that. > > A comparable case is exact real vs. interval arithmetic. We don't need > exact exception propagation analysis, we do a conservative *estimation* of. Right, but a the only possible conservative estimate is that all code can propagate Program_Error, Constraint_Error, and Storage_Error. Even exception when others => null; can raise Storage_Error and Program_Error (from finalization). And if you replace "null" with a subprogram call, you will probably introduce Constraint_Error. Unless you do quite a bit of static analysis, you can't prove *anything* useful about what exceptions can propagate. Java solves this by excluding the predefined exceptions, but all that does is makes the contracts useless -- you don't really know what might propagate. I hardly ever have problems with user-defined exceptions like Windows_Error or Not_Valid_Error (from Claw, as an example) propagating: the "comment" contracts make it pretty clear what can happen, and expected errors are quickly handled. Without some sort of static analysis required, all access dereferences *can* raise Constraint_Error, all integer assignments can raise Constraint_Error, and so on. Since we want all Ada compilers to work the same (so code is portable), you would have to define what exact rules you are allowed to use for determining whether an exception is raised, and which ones you are not. That is a significant effort, and is going to be hard for some compilers to implement -- moreover, compilers that know more would have to be prohibited from using it. None of that seems good. Randy. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-08 3:30 ` Exceptions Randy Brukardt 2007-12-08 10:09 ` Contracted exceptions for Ada (was: Exceptions) Dmitry A. Kazakov @ 2007-12-08 12:26 ` Peter C. Chapin 2007-12-08 14:01 ` Exceptions Dmitry A. Kazakov 1 sibling, 1 reply; 97+ messages in thread From: Peter C. Chapin @ 2007-12-08 12:26 UTC (permalink / raw) Randy Brukardt wrote: > The ARG has discussed "exception contracts" a couple of times, but there > didn't seem that there was enough interest... These sort of issues have also been discussed at length in the C++ community, mostly in the context of why C++'s exception specifications were a mistake. In those discussions I've heard many reasonable people also express the opinion that Java's statically enforced exception specifications were a bad idea. The problem often quoted is that there are cases where an exception looks like it could happen, but for reasons the compiler doesn't know can't actually happen. As a simple example consider the code fragment if Has_Acceptable_Value(X) then P1(X); P2(X); P3(X): end if; Suppose P1 raises an exception if X is negative. Depending on what Has_Acceptable_Value does, it is quite possible that can't happen in the code above. If you specify exception contracts the way Java did, then the programmer in the above case ends up having to handle an exception that won't happen or claim to propagate and exception that won't get propagated. Either option is undesirable. While one could argue that it is safest to assume the exception might happen anyway (since Has_Acceptable_Value might change or be incorrect), forcing empty handlers all over the place to cover such possibilities doesn't seem right either. In fact, such handlers would probably eat the unexpected exceptions and actually prevent buggy from being discovered and fixed. In this respect exception contracts might actually reduce reliability rather than promote it. C++ checks exception specifications at run time, but then it's hard to know what to do when a check fails. C++ throws a different exception in that case, but that doesn't really solve anything as far as I can see. The C++ community seems to have concluded that being able to declare a function as throwing no exceptions is potentially useful, but that there is little point in trying to go beyond that. It seems like Ada got this right by not attempting to provide language based exception contracts. Adding such contracts to Ada might well be taking the language in the wrong direction. Peter ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-08 12:26 ` Exceptions Peter C. Chapin @ 2007-12-08 14:01 ` Dmitry A. Kazakov 2007-12-08 18:01 ` Exceptions Peter C. Chapin 0 siblings, 1 reply; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-08 14:01 UTC (permalink / raw) On Sat, 08 Dec 2007 07:26:21 -0500, Peter C. Chapin wrote: > The problem often quoted is that there are cases where an exception > looks like it could happen, but for reasons the compiler doesn't know > can't actually happen. As a simple example consider the code fragment > > if Has_Acceptable_Value(X) then > P1(X); > P2(X); > P3(X): > end if; > > Suppose P1 raises an exception if X is negative. Depending on what > Has_Acceptable_Value does, it is quite possible that can't happen in the > code above. If you specify exception contracts the way Java did, then > the programmer in the above case ends up having to handle an exception > that won't happen or claim to propagate and exception that won't get > propagated. Either option is undesirable. The problem here is not exception contracts but firstly lack of subtypes in C++. Ada has subtypes, so the code above could be rewritten [properly]: if X in Safe_For_P1 then declare Checked_X : Safe_For_P1 renames X; begin P1 (Checked_X); -- This does not raise exception The actual problem for Ada is that there is no syntax sugar for "if X in S then X indeed in S" (:-)) This is not about exceptions, we also do if Ptr /= null then Foo (Ptr.all); No way to assure that Ptr cannot be null in Ptr.all to require the compiler to drop checks. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-08 14:01 ` Exceptions Dmitry A. Kazakov @ 2007-12-08 18:01 ` Peter C. Chapin 2007-12-09 10:06 ` Exceptions Dmitry A. Kazakov 2007-12-09 10:24 ` Exceptions Stephen Leake 0 siblings, 2 replies; 97+ messages in thread From: Peter C. Chapin @ 2007-12-08 18:01 UTC (permalink / raw) Dmitry A. Kazakov wrote: > The problem here is not exception contracts but firstly lack of subtypes in > C++. Ada has subtypes, so the code above could be rewritten [properly]: > > if X in Safe_For_P1 then > declare > Checked_X : Safe_For_P1 renames X; > begin > P1 (Checked_X); -- This does not raise exception Here is my example again: if Has_Acceptable_Value(X) then P1(X); end if; What if Has_Acceptable_Value(X) returns true if X is prime... or a positive power of two? I don't believe you can use Ada subtypes to express conditions like that---or indeed many other possibilities. However, since primes (or positive powers of two, etc) aren't negative, my earlier point is still valid. The above code won't raise the exception in P1 (assume P1 only raises for negative arguments) so handling it or claiming to propagate it is a waste of resources and misleading. Peter ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-08 18:01 ` Exceptions Peter C. Chapin @ 2007-12-09 10:06 ` Dmitry A. Kazakov 2007-12-09 12:40 ` Exceptions Peter C. Chapin 2007-12-09 10:24 ` Exceptions Stephen Leake 1 sibling, 1 reply; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-09 10:06 UTC (permalink / raw) On Sat, 08 Dec 2007 13:01:13 -0500, Peter C. Chapin wrote: > Dmitry A. Kazakov wrote: > >> The problem here is not exception contracts but firstly lack of subtypes in >> C++. Ada has subtypes, so the code above could be rewritten [properly]: >> >> if X in Safe_For_P1 then >> declare >> Checked_X : Safe_For_P1 renames X; >> begin >> P1 (Checked_X); -- This does not raise exception > > Here is my example again: > > if Has_Acceptable_Value(X) then > P1(X); > end if; > > What if Has_Acceptable_Value(X) returns true if X is prime... or a > positive power of two? I don't believe you can use Ada subtypes to > express conditions like that---or indeed many other possibilities. Yes, but it that case very design of P1 is in question. Why the set of values where P1 is defined does not constitute some semantically integral body (like a subtype)? P1 is an operation of what? Maybe I would not use exceptions in P1, or else mark the caller of P1 as propagating the exception of P1. > However, since primes (or positive powers of two, etc) aren't negative, > my earlier point is still valid. The above code won't raise the > exception in P1 (assume P1 only raises for negative arguments) so > handling it or claiming to propagate it is a waste of resources and > misleading. On the contrary, if I decided to use an exception in P1, then I would see it as an advantage that the language would force me to put a handler around P1, because semantic relation between Has_Acceptable_Value and P1 is not obvious since there is no subtype. Later me or another maintainer of the code will certainly forget about any relation between them and mistakenly remove if Has_Acceptable_Value. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-09 10:06 ` Exceptions Dmitry A. Kazakov @ 2007-12-09 12:40 ` Peter C. Chapin 2007-12-09 14:31 ` Exceptions Dmitry A. Kazakov 2007-12-09 21:56 ` Exceptions Robert A Duff 0 siblings, 2 replies; 97+ messages in thread From: Peter C. Chapin @ 2007-12-09 12:40 UTC (permalink / raw) Dmitry A. Kazakov wrote: >> if Has_Acceptable_Value(X) then >> P1(X); >> end if; >> >> What if Has_Acceptable_Value(X) returns true if X is prime... or a >> positive power of two? I don't believe you can use Ada subtypes to >> express conditions like that---or indeed many other possibilities. > > Yes, but it that case very design of P1 is in question. Why the set of > values where P1 is defined does not constitute some semantically integral > body (like a subtype)? Well, my example above is a bit contrived. Let's consider a couple of more realistic examples: 1. X is a string. Has_Acceptable_Value returns true if X is the name field of some record in a database. The procedure P1 executes some string handling algorithm that happens to not be meaningful for empty strings. Thus P1 raises an exception if given such a string. Yet, due to database constraints (let's say), any X that causes Has_Acceptable_Value to return true won't be empty so the exception never arises. 2. X is an abstract type representing an XML document. Has_Acceptable_Value returns true if X is valid according to its declared schema. P1 does some XML processing but it assumes the document given to it is well formed and raises exceptions if that is not the case. Since valid documents are also well formed, those exceptions won't occur once Has_Acceptable_Value has signed off on X. Indeed, this is one of the main reasons why validating documents before processing them is desirable: it simplifies later error handling. If I understand what you are saying, one would need to define a subtype of strings that contains all strings but the empty string (for #1) or a subtype of my abstract type that contains all valid XML documents (for #2). Can those things be expressed using Ada subtypes? I suppose it could be done using type derivation, but is invoking that machinery really better than just ignoring the possibility that P1 will raise and letting any unexpected exceptions propagate in the usual way? The issue is particularly acute when there is an else clause on the if. if Is_Valid_XML(X) then Process_Document(X); else Log_Bad_Document(X); end if; Suppose the above is inside a loop that runs over a collection of documents. Do we really want to include a handler for Not_Well_Formed_Exception in this procedure just because the contract on Process_Document says it might raise such an exception? Do we really want to claim that we propagate that exception when we clearly don't? You might say that in a careful program (for example in a high integrity program) unexpected exceptions should not be treated in such a cavalier manner. I would agree with that. The question is should the language attempt to force that degree of care on all programs? It's a balance between usability and safety. As with all things related to security, overly aggressive policies can backfire when people feel the need to do silly things to work around them. I suppose at the end of the day it's really just a matter of taste... which is what makes debates like this possible. :-) Peter ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-09 12:40 ` Exceptions Peter C. Chapin @ 2007-12-09 14:31 ` Dmitry A. Kazakov 2007-12-09 16:38 ` Exceptions Peter C. Chapin 2007-12-09 21:56 ` Exceptions Robert A Duff 1 sibling, 1 reply; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-09 14:31 UTC (permalink / raw) On Sun, 09 Dec 2007 07:40:45 -0500, Peter C. Chapin wrote: > Dmitry A. Kazakov wrote: > >>> if Has_Acceptable_Value(X) then >>> P1(X); >>> end if; >>> >>> What if Has_Acceptable_Value(X) returns true if X is prime... or a >>> positive power of two? I don't believe you can use Ada subtypes to >>> express conditions like that---or indeed many other possibilities. >> >> Yes, but it that case very design of P1 is in question. Why the set of >> values where P1 is defined does not constitute some semantically integral >> body (like a subtype)? > > Well, my example above is a bit contrived. Let's consider a couple of > more realistic examples: > > 1. X is a string. Has_Acceptable_Value returns true if X is the name > field of some record in a database. The procedure P1 executes some > string handling algorithm that happens to not be meaningful for empty > strings. Thus P1 raises an exception if given such a string. Yet, due to > database constraints (let's say), any X that causes Has_Acceptable_Value > to return true won't be empty so the exception never arises. Then I would propose: begin P1 (X); exception when Empty_String_Error => -- do something else end; If the point is that exception propagation is too expensive for the caller of P1 then again, why wasn't it for P1? Bad design? > 2. X is an abstract type representing an XML document. > Has_Acceptable_Value returns true if X is valid according to its > declared schema. P1 does some XML processing but it assumes the document > given to it is well formed and raises exceptions if that is not the > case. Since valid documents are also well formed, those exceptions won't > occur once Has_Acceptable_Value has signed off on X. Indeed, this is one > of the main reasons why validating documents before processing them is > desirable: it simplifies later error handling. Isn't this indeed a waste of resources? Validation is performed twice, once in Has_Acceptable_Value and once in P1! Isn't this design actually based on a presumption that P1 does something wrong, while Has_Acceptable_Value would do it right? Wouldn't it better just to fix P1? And for all, I bet that exception propagation in most cases will be far more efficient than an extra document parsing. > If I understand what you are saying, one would need to define a subtype > of strings that contains all strings but the empty string (for #1) or a > subtype of my abstract type that contains all valid XML documents (for > #2). Can those things be expressed using Ada subtypes? I suppose it > could be done using type derivation, but is invoking that machinery > really better than just ignoring the possibility that P1 will raise and > letting any unexpected exceptions propagate in the usual way? My point is that if there exist problems then they lie by possible weaknesses of the language subtyping system rather than by contracts for exceptions. > The issue is particularly acute when there is an else clause on the if. > > if Is_Valid_XML(X) then > Process_Document(X); > else > Log_Bad_Document(X); > end if; > > Suppose the above is inside a loop that runs over a collection of > documents. Do we really want to include a handler for > Not_Well_Formed_Exception in this procedure just because the contract on > Process_Document says it might raise such an exception? Do we really > want to claim that we propagate that exception when we clearly don't? I want to propagate it. If the design foresaw exception propagation (and contract says so), then I just handle that exception explicitly. To me begin Process_Document (X); exception when Reason : Format_Error => Log_Bad_Document (Reason); end; is much cleaner and also more efficient. If some extra analysis of X has to done then I would do it in the exception handler after the problem has manifested itself. The universal principle is never run ahead of the locomotive... (:-)) > You might say that in a careful program (for example in a high integrity > program) unexpected exceptions should not be treated in such a cavalier > manner. I would agree with that. The question is should the language > attempt to force that degree of care on all programs? YES! Otherwise I would use Visual Basic. (:-)) > It's a balance > between usability and safety. As with all things related to security, > overly aggressive policies can backfire when people feel the need to do > silly things to work around them. I suppose at the end of the day it's > really just a matter of taste... which is what makes debates like this > possible. :-) Talking about balance. It is not about high integrity applications. In recent times I have been using a lot of GTK+ (under GtkAda). I cannot tell for AdaCore people developing GPS, but as for me, GTK+ makes me sick. Roughly 90% of all errors I spent the debugging time on was about exceptions propagating from Ada into GTK and then crashing it. It is a mess, and there is no any way to deal with that, because GTK+ is not Ada and its design contradicts to very foundations of. Analysis of these cases clearly shows that these bugs could be caught at compile time if we had exception contracts. I don't see how lacking it could add any usability. It does otherwise. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-09 14:31 ` Exceptions Dmitry A. Kazakov @ 2007-12-09 16:38 ` Peter C. Chapin 2007-12-10 8:31 ` Exceptions Dmitry A. Kazakov 0 siblings, 1 reply; 97+ messages in thread From: Peter C. Chapin @ 2007-12-09 16:38 UTC (permalink / raw) Dmitry A. Kazakov wrote: > Then I would propose: > > begin > P1 (X); > exception > when Empty_String_Error => > -- do something else > end; I only want X to contain a name from the database. I have to check for that someplace regardless of what P1 wants to do. Checking for it inside P1 doesn't work because P1 is a general purpose string handling algorithm that knows nothing about my application. > Isn't this indeed a waste of resources? Validation is performed twice, once > in Has_Acceptable_Value and once in P1! In this example P1 doesn't validate. It just assumes the document is valid and skips as much error handling as possible. However P1, or subprograms it calls, might have the potential of raising a variety of exceptions, including perhaps C_E if P1 is inadvertently given an invalid document. In XML based applications I've written, I validate the document once and then let the rest of the program just assume it is valid. This means there are all kinds of error situations I can ignore because they aren't possible in a valid document. This lets me abbreviate not just one procedure (like P1), but many procedures. Peter ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-09 16:38 ` Exceptions Peter C. Chapin @ 2007-12-10 8:31 ` Dmitry A. Kazakov 0 siblings, 0 replies; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-10 8:31 UTC (permalink / raw) On Sun, 09 Dec 2007 11:38:46 -0500, Peter C. Chapin wrote: > Dmitry A. Kazakov wrote: > >> Then I would propose: >> >> begin >> P1 (X); >> exception >> when Empty_String_Error => >> -- do something else >> end; > > I only want X to contain a name from the database. I have to check for > that someplace regardless of what P1 wants to do. Checking for it inside > P1 doesn't work because P1 is a general purpose string handling > algorithm that knows nothing about my application. Then I didn't understand the example. If P1 does not check X why should it raise any exception? >> Isn't this indeed a waste of resources? Validation is performed twice, once >> in Has_Acceptable_Value and once in P1! > > In this example P1 doesn't validate. It just assumes the document is > valid and skips as much error handling as possible. However P1, or > subprograms it calls, might have the potential of raising a variety of > exceptions, including perhaps C_E if P1 is inadvertently given an > invalid document. In that case you just cannot say that P1 does not propagate Constraint_Error, because it is too difficult to spell the conditions of propagation. You put all trust in some Validate (X), which is designed independently on P1. How can you be certain that Validate indeed prevents Constraint_Error in P1? I would never do, so a handler for Constraint_Error looks quite appropriate to me. > In XML based applications I've written, I validate the document once and > then let the rest of the program just assume it is valid. OK, I would parse once, but that is another story. My point is that handler were a good idea because Validate and P1 are decoupled. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-09 12:40 ` Exceptions Peter C. Chapin 2007-12-09 14:31 ` Exceptions Dmitry A. Kazakov @ 2007-12-09 21:56 ` Robert A Duff 1 sibling, 0 replies; 97+ messages in thread From: Robert A Duff @ 2007-12-09 21:56 UTC (permalink / raw) "Peter C. Chapin" <pchapin@sover.net> writes: > 2. X is an abstract type representing an XML document. > Has_Acceptable_Value returns true if X is valid according to its > declared schema. P1 does some XML processing but it assumes the document > given to it is well formed and raises exceptions if that is not the > case. Since valid documents are also well formed, those exceptions won't > occur once Has_Acceptable_Value has signed off on X. Indeed, this is one > of the main reasons why validating documents before processing them is > desirable: it simplifies later error handling. Right. A similar example is a compiler. E.g. in GNAT, the semantic analysis phase assumes that the tree produced by the parser is syntactically correct. And the code generator assumes that the program is legal. > Suppose the above is inside a loop that runs over a collection of > documents. Do we really want to include a handler for > Not_Well_Formed_Exception in this procedure just because the contract on > Process_Document says it might raise such an exception? Well, we at least want a comment saying why the exception that "might" be raised will not be raised in this case. And "when Blah => raise Bug; -- ..." seems like a good way to say that. >...Do we really > want to claim that we propagate that exception when we clearly don't? No. That would spread noise around the whole program. > You might say that in a careful program (for example in a high integrity > program) unexpected exceptions should not be treated in such a cavalier > manner. I would agree with that. The question is should the language > attempt to force that degree of care on all programs? It's a balance > between usability and safety. As with all things related to security, > overly aggressive policies can backfire when people feel the need to do > silly things to work around them. I suppose at the end of the day it's > really just a matter of taste... which is what makes debates like this > possible. :-) How can it be a matter of taste? Checked exceptions either improve the code or they don't. Maybe it depends on the application area. But I don't see how it can depend on taste. - Bob ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-08 18:01 ` Exceptions Peter C. Chapin 2007-12-09 10:06 ` Exceptions Dmitry A. Kazakov @ 2007-12-09 10:24 ` Stephen Leake 2007-12-09 12:46 ` Exceptions Peter C. Chapin 1 sibling, 1 reply; 97+ messages in thread From: Stephen Leake @ 2007-12-09 10:24 UTC (permalink / raw) "Peter C. Chapin" <pchapin@sover.net> writes: > Dmitry A. Kazakov wrote: > >> The problem here is not exception contracts but firstly lack of subtypes in >> C++. Ada has subtypes, so the code above could be rewritten [properly]: >> >> if X in Safe_For_P1 then >> declare >> Checked_X : Safe_For_P1 renames X; >> begin >> P1 (Checked_X); -- This does not raise exception > > Here is my example again: > > if Has_Acceptable_Value(X) then > P1(X); > end if; > > What if Has_Acceptable_Value(X) returns true if X is prime... or a > positive power of two? I don't believe you can use Ada subtypes to > express conditions like that---or indeed many other possibilities. Right. You have to use SPARK Ada. -- -- Stephe ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-09 10:24 ` Exceptions Stephen Leake @ 2007-12-09 12:46 ` Peter C. Chapin 0 siblings, 0 replies; 97+ messages in thread From: Peter C. Chapin @ 2007-12-09 12:46 UTC (permalink / raw) Stephen Leake wrote: > Right. You have to use SPARK Ada. I could be wrong, but I was under the impression that the SPARK subset disallowed exceptions entirely because they are too difficult to analyze. If so, the only exceptions that might occur in a SPARK program are the predefined ones; and as I understand it the SPARK tool set gives you a way to prove, under certain circumstances, that even those will not occur. Not being a heavy SPARK user, however, I could be off base here. Peter ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-06 21:24 ` Exceptions tmoran 2007-12-07 8:54 ` Exceptions Dmitry A. Kazakov @ 2007-12-09 21:39 ` Robert A Duff 2007-12-09 22:13 ` Exceptions Georg Bauhaus 2007-12-12 19:18 ` Exceptions Martin Krischik 1 sibling, 2 replies; 97+ messages in thread From: Robert A Duff @ 2007-12-09 21:39 UTC (permalink / raw) tmoran@acm.org writes: >>Is there any way to force programmers to catch exception that >>your function throws? > Do you mean force them to write code like: > begin > y := func(x); > exception > when funcs_important_exception=>null; -- ignore unimportant exception > end; I've heard that this is a common problem in Java code. Compiler complains, so the programmer puts in an exception-ignoring handler -- probably without any comment explaining why. But I don't get it. If you think a certain exception is impossible in a certain case, and the compiler insists on a handler, the obvious thing to do is raise an unchecked exception. In Ada: when Funcs_Important_Exception => -- <comment explaining why this can never happen> raise Program_Error; Why on earth would anybody write "null;" there?! I don't blame the Java language design for this problem. - Bob ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-09 21:39 ` Exceptions Robert A Duff @ 2007-12-09 22:13 ` Georg Bauhaus 2007-12-11 8:07 ` Exceptions Stephen Leake 2007-12-12 19:18 ` Exceptions Martin Krischik 1 sibling, 1 reply; 97+ messages in thread From: Georg Bauhaus @ 2007-12-09 22:13 UTC (permalink / raw) Robert A Duff wrote: > when Funcs_Important_Exception => > -- <comment explaining why this can never happen> > raise Program_Error; > > Why on earth would anybody write "null;" there?! > "We know that when this library routine complains, it doesn't concern us. Besides, why should we pester the customer or the user with messages and tracebacks that do not matter?" (In some cultures, openly announcing errors is not the preferred strategy ;-) The idea is that the frame of reference for inventing the name "Funcs_Important_Exception" is somebody else's. The source code equivalent of this Don't Care is the missing comment, quite consequently---even if at another level of reasoning. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-09 22:13 ` Exceptions Georg Bauhaus @ 2007-12-11 8:07 ` Stephen Leake 2007-12-11 20:28 ` Exceptions Simon Wright 2007-12-12 22:10 ` Exceptions Maciej Sobczak 0 siblings, 2 replies; 97+ messages in thread From: Stephen Leake @ 2007-12-11 8:07 UTC (permalink / raw) Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de> writes: > Robert A Duff wrote: > >> when Funcs_Important_Exception => >> -- <comment explaining why this can never happen> >> raise Program_Error; >> Why on earth would anybody write "null;" there?! >> > > "We know that when this library routine complains, > it doesn't concern us. Besides, why should we pester > the customer or the user with messages and tracebacks that > do not matter?" (In some cultures, openly announcing errors > is not the preferred strategy ;-) For third party libraries that I can't fix, I agree; I have code like that myself. Although I also strive to change the way I use the library to avoid the bug, but sometimes that's not possible. For code I have control over, I agree with Bob, except I use a different exception; raise Programmer_Error if you've detected a bug. -- -- Stephe ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-11 8:07 ` Exceptions Stephen Leake @ 2007-12-11 20:28 ` Simon Wright 2007-12-12 22:10 ` Exceptions Maciej Sobczak 1 sibling, 0 replies; 97+ messages in thread From: Simon Wright @ 2007-12-11 20:28 UTC (permalink / raw) Stephen Leake <stephen_leake@stephe-leake.org> writes: > For code I have control over, I agree with Bob, except I use a > different exception; raise Programmer_Error if you've detected a > bug. neat! ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-11 8:07 ` Exceptions Stephen Leake 2007-12-11 20:28 ` Exceptions Simon Wright @ 2007-12-12 22:10 ` Maciej Sobczak 2007-12-13 13:40 ` Exceptions Robert A Duff 1 sibling, 1 reply; 97+ messages in thread From: Maciej Sobczak @ 2007-12-12 22:10 UTC (permalink / raw) On 11 Gru, 09:07, Stephen Leake <stephen_le...@stephe-leake.org> wrote: > For code I have control over, I agree with Bob, except I use a > different exception; raise Programmer_Error if you've detected a bug. I understand that this way you want to signal something much more severe than "mere" Constraint_Error or such. The problem is that Program_Error can be shut up by some null handler or it can be translated to some other exception and then lose its original weight. Why not terminating the program right on the spot by simply: pragma Assert (False); ? (yes, there are compiler options to switch it off as well) Does anybody use this strategy in regular code? I happen to use it in test units and I find it very appropriate there. Any thoughts on using assertions, including Assert(False), in production code? -- Maciej Sobczak * www.msobczak.com * www.inspirel.com ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-12 22:10 ` Exceptions Maciej Sobczak @ 2007-12-13 13:40 ` Robert A Duff 2007-12-13 14:00 ` Exceptions Maciej Sobczak 0 siblings, 1 reply; 97+ messages in thread From: Robert A Duff @ 2007-12-13 13:40 UTC (permalink / raw) Maciej Sobczak <see.my.homepage@gmail.com> writes: > On 11 Gru, 09:07, Stephen Leake <stephen_le...@stephe-leake.org> > wrote: > >> For code I have control over, I agree with Bob, except I use a >> different exception; raise Programmer_Error if you've detected a bug. > > I understand that this way you want to signal something much more > severe than "mere" Constraint_Error or such. > The problem is that Program_Error can be shut up by some null handler > or it can be translated to some other exception and then lose its > original weight. The solution to "when others => null;" and the like is better education. Competent programmers need to know not to do that, except in rare cases, where a big fat comment is in order. (Unfortunately, the designers of Ada 83 made exactly this mistake for task bodies! And Ada 95 repeats it for interrupt handlers.) I don't consider Constraint_Error "mere", by the way. It almost always represents a bug. > Why not terminating the program right on the spot by simply: > > pragma Assert (False); > > ? That doesn't terminate the program on the spot. It raises Assertion_Failure. I consider all of these: pragma Assert (False); Assert (False); -- Assert is a user-defined procedure raise Program_Error; raise Bug; -- Bug is a user-defined exception used project-wide to be legitimate ways of reporting a self-detected bug. There ought to be a standard predefined procedure for stopping the program "on the spot". Since there isn't, you can import "exit". > (yes, there are compiler options to switch it off as well) Indeed, it's turned off by default in GNAT (which I don't much like). > Does anybody use this strategy in regular code? > I happen to use it in test units and I find it very appropriate there. > Any thoughts on using assertions, including Assert(False), in > production code? Nothing wrong with using assertions in production code. - Bob ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-13 13:40 ` Exceptions Robert A Duff @ 2007-12-13 14:00 ` Maciej Sobczak 2007-12-13 14:44 ` Exceptions Robert A Duff 2007-12-13 19:29 ` Exceptions Randy Brukardt 0 siblings, 2 replies; 97+ messages in thread From: Maciej Sobczak @ 2007-12-13 14:00 UTC (permalink / raw) On 13 Gru, 14:40, Robert A Duff <bobd...@shell01.TheWorld.com> wrote: > The solution to "when others => null;" and the like is better > education. Isn't it also a solution for all the presumed problems of C/C++? Sorry, could not resist. ;-) > I don't consider Constraint_Error "mere", by the way. > It almost always represents a bug. What about a situation when a user entered an input data that was outside of legal (and documented) range? Or that caused our of range value further down the pipe? This is not necessarily a bug, just an indication that the value is out of range. The exception can help to come back to the input loop and repeat the user scenario, abandoning all the state that was created in the meanime. This way the program does not enter into any abnormal state. > > Why not terminating the program right on the spot by simply: > > > pragma Assert (False); > That doesn't terminate the program on the spot. > It raises Assertion_Failure. Right. I was somehow convinced that Assert has this magic property of switching the world off, like the assert macro in C and C++. > I consider all of these: > > pragma Assert (False); > Assert (False); -- Assert is a user-defined procedure > raise Program_Error; > raise Bug; -- Bug is a user-defined exception used project-wide > > to be legitimate ways of reporting a self-detected bug. OK, this sounds reasonable. > There ought to be a standard predefined procedure for stopping the > program "on the spot". Since there isn't, you can import "exit". I was wandering whether there is any standard mechanism for this. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-13 14:00 ` Exceptions Maciej Sobczak @ 2007-12-13 14:44 ` Robert A Duff 2007-12-14 0:46 ` Exceptions Ray Blaak 2007-12-13 19:29 ` Exceptions Randy Brukardt 1 sibling, 1 reply; 97+ messages in thread From: Robert A Duff @ 2007-12-13 14:44 UTC (permalink / raw) Maciej Sobczak <see.my.homepage@gmail.com> writes: > On 13 Gru, 14:40, Robert A Duff <bobd...@shell01.TheWorld.com> wrote: > >> The solution to "when others => null;" and the like is better >> education. > > Isn't it also a solution for all the presumed problems of C/C++? > Sorry, could not resist. ;-) I see the smiley, but... Here's a serious reply anyway: A language design should not try to prevent people from doing bad things. It should try to prevent people from doing bad things BY ACCIDENT. The Java programmers who have been mentioned several times in this thread -- the ones who evilly stick in do-nothing handlers -- are doing so on purpose. Any attempt to fix that problem via language design will backfire. Fixing it via education OTOH has a good chance of success. Forgetting to handle an exception, however, is an accident. A language design can help there, but education will not. >> I don't consider Constraint_Error "mere", by the way. >> It almost always represents a bug. > > What about a situation when a user entered an input data that was > outside of legal (and documented) range? Or that caused our of range > value further down the pipe? > This is not necessarily a bug, just an indication that the value is > out of range. The exception can help to come back to the input loop > and repeat the user scenario, abandoning all the state that was > created in the meanime. This way the program does not enter into any > abnormal state. Well, you can't refute an "almost always" statement by giving a counterexample. ;-) Yes, in the situation you mention, it's reasonable to say: when Constraint_Error => null; -- loop back and ask user again I've got no problem with that, so long as there's a good comment. It should not be "when others" in this case, either. >> There ought to be a standard predefined procedure for stopping the >> program "on the spot". Since there isn't, you can import "exit". > > I was wandering whether there is any standard mechanism for this. You can abort the environment task. But I'm not sure what that will do in a multi-threaded, multi-language program -- depends on the implementation. Anyway, it's an ugly trick. I'd rather be able to portably say "Kill_Program;" or "Kill_Program(exit_code);" or something like that. Note that you need to think carefully about whether you want finalizers to run. - Bob ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-13 14:44 ` Exceptions Robert A Duff @ 2007-12-14 0:46 ` Ray Blaak 2007-12-14 2:36 ` Exceptions Randy Brukardt 2007-12-14 17:29 ` Exceptions Robert A Duff 0 siblings, 2 replies; 97+ messages in thread From: Ray Blaak @ 2007-12-14 0:46 UTC (permalink / raw) Robert A Duff <bobduff@shell01.TheWorld.com> writes: > The Java programmers who have been mentioned several times in this > thread -- the ones who evilly stick in do-nothing handlers -- are doing > so on purpose. Any attempt to fix that problem via language design will > backfire. Fixing it via education OTOH has a good chance of success. I used to "believe" in checked exception handling, my Ada experience being the likely inspiration. Long experience with Java code leads me to believe they cause more problems then they solve, simply due to the fact that the majority of programmers are coding at a junior or "naive" level. So, when the compiler demands an exception handler, then by golly they provide one -- one that simply swallows the exception with a log of the stack trace. This is in fact far worse than not handling the exception at all, since control flow is not aborted. So, the junior programmer evilly stuck in a do-nothing handler, but they had no clue they were being evil. Note also that the theoretical correctness of whether or not checked exceptions are better is not being disputed here -- the answer is irrelevant. The *practical* effect of checked exceptions, at least with junior programmers, tends, in Java at least, to cause worse results than not handling the exception at all. So, C#'s approach of not having checked exceptions is turning out to be a better design decision in practice, in my experience. Another point is to consider what one usually does with a handled exception. Usually it is to ultimately report it or log it in some manner. Primarily it needs to perculate up to a top level, where some sort of central event loop can be reset. Sometimes some cleanup needs to be done, but that cleanup often tends to be needed for any exception that is thrown, and the exception should often be rethrown anyway so as to continue to abort the control flow. My experience is that most code does not need to handle exceptions at all except at well defined points in the top level. Mind you, with the use of a non-garbage collected language like Ada, one would need to do cleanups with exceptions more often, but that does not imply the need to do specific exception handling. The times I have seen the need for exception specific handling is usually to do with error message generation. Some exceptions need to show stack traces, some need to show different messages, some need to be shown to the user, etc. This kind of thing is easier to centralize in a language where exceptions are first class objects, since one can override exception behaviour (e.g. anything extending from UserException will be shown to the user, anything else will be logged with a stack trace, with only an "unexpected error" shown to the user, paprticular error reasons are shown via overriding the getMessage() method, etc.). I note also that recent APIs for Java (e.g. XML DOM, Joda data/time, D4Bo OODB) tend to use unchecked exceptions in their APIs, since it makes development so much easier for writing and maintaining code against those APIs. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-14 0:46 ` Exceptions Ray Blaak @ 2007-12-14 2:36 ` Randy Brukardt 2007-12-14 6:21 ` Exceptions Ray Blaak 2007-12-14 17:29 ` Exceptions Robert A Duff 1 sibling, 1 reply; 97+ messages in thread From: Randy Brukardt @ 2007-12-14 2:36 UTC (permalink / raw) "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message news:u4pem6r3t.fsf@STRIPCAPStelus.net... ... > Mind you, with the use of a non-garbage collected language like Ada, one would > need to do cleanups with exceptions more often, but that does not imply the > need to do specific exception handling. I generally agree with you, but there is one case where you need to do specific exception handling: when you need to change one exception into another. For instance, the specification for Ada.Text_IO says that a Get of an integer that is out of range raises Data_Error. If you write that code in Ada (and I think most of us implementers did), you probably had to handle Constraint_Error somewhere and then raise Data_Error instead. I find that this sort of handler is fairly common if you use user-defined exceptions in your packages. Randy. P.S. Ada programmers *raise* exceptions. The only thing that Ada programmers "throw" is the trash into the trash can... ;-) ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-14 2:36 ` Exceptions Randy Brukardt @ 2007-12-14 6:21 ` Ray Blaak 2007-12-14 12:40 ` Exceptions Georg Bauhaus 0 siblings, 1 reply; 97+ messages in thread From: Ray Blaak @ 2007-12-14 6:21 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > I generally agree with you, but there is one case where you need to do > specific exception handling: when you need to change one exception into > another. Ok, it has to be said again: exceptions need to be first class objects. Changing an exception into another is trivial in most languages, typically by wrapping it with another of the desired kind. Ada's difficulties with manipulating exceptions are completely self induced. > P.S. Ada programmers *raise* exceptions. The only thing that Ada programmers > "throw" is the trash into the trash can... ;-) Real languages don't have a trash can. There is a janitor in the background cleaning everything up. Exceptions are the only thing left to throw >-). Ada is a pretty good language. Garbage collection is a step up the evolutionary ladder though, and needs to be available within Ada as well, perhaps under programmer control to be disabled when necessary. Google some previous threads for my arguments on this topic. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-14 6:21 ` Exceptions Ray Blaak @ 2007-12-14 12:40 ` Georg Bauhaus 0 siblings, 0 replies; 97+ messages in thread From: Georg Bauhaus @ 2007-12-14 12:40 UTC (permalink / raw) Ray Blaak wrote: > "Randy Brukardt" <randy@rrsoftware.com> writes: >> I generally agree with you, but there is one case where you need to do >> specific exception handling: when you need to change one exception into >> another. > > Ok, it has to be said again: exceptions need to be first class objects. Or, exceptions need to stay the way they are for the exceptional case of something going wrong(!) but we need a mechanism for safely signaling information up the call chain in a specially controlled fashion (the algorithmic use of "exception objects"). ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-14 0:46 ` Exceptions Ray Blaak 2007-12-14 2:36 ` Exceptions Randy Brukardt @ 2007-12-14 17:29 ` Robert A Duff 2007-12-14 19:32 ` Exceptions Dmitry A. Kazakov 2007-12-15 5:29 ` Exceptions Ray Blaak 1 sibling, 2 replies; 97+ messages in thread From: Robert A Duff @ 2007-12-14 17:29 UTC (permalink / raw) Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes: > Long experience with Java code leads me to believe they cause more problems > then they solve, simply due to the fact that the majority of programmers are > coding at a junior or "naive" level. > > So, when the compiler demands an exception handler, then by golly they > provide one -- one that simply swallows the exception with a log of > the stack trace. This is what I don't get. I know there are lots of not-so-good programmers around, but how hard could it be to teach that "junior" programmer how to do this particular thing right? It's not "rocket science". ;-) And if the programmer can't learn this much, maybe they don't have much aptitude for programming in the first place. > This is in fact far worse than not handling the exception at all, since > control flow is not aborted. Indeed. That's why exceptions are a good idea in the first place -- their default behavior is to STOP, as opposed to forging ahead blindly causing who-knows-what chaos. > So, the junior programmer evilly stuck in a do-nothing handler, but they had > no clue they were being evil. ... and the senior programmer reviews the code, and gives the junior one a few tips, and pretty soon ... <oh, never mind> ;-) - Bob ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-14 17:29 ` Exceptions Robert A Duff @ 2007-12-14 19:32 ` Dmitry A. Kazakov 2007-12-15 5:29 ` Exceptions Ray Blaak 1 sibling, 0 replies; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-14 19:32 UTC (permalink / raw) On Fri, 14 Dec 2007 12:29:01 -0500, Robert A Duff wrote: > Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes: > >> Long experience with Java code leads me to believe they cause more problems >> then they solve, simply due to the fact that the majority of programmers are >> coding at a junior or "naive" level. >> >> So, when the compiler demands an exception handler, then by golly they >> provide one -- one that simply swallows the exception with a log of >> the stack trace. > > This is what I don't get. I know there are lots of not-so-good > programmers around, but how hard could it be to teach that "junior" > programmer how to do this particular thing right? It's not "rocket > science". ;-) And if the programmer can't learn this much, maybe > they don't have much aptitude for programming in the first place. The actual problem is exceptions misused for debugging. A "senior" programmer would compensate this wrong design, while a "junior" one would just add more mess. For debugging there were enough to have some sort of "stop at once" statement (with breaking into the debugger.) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-14 17:29 ` Exceptions Robert A Duff 2007-12-14 19:32 ` Exceptions Dmitry A. Kazakov @ 2007-12-15 5:29 ` Ray Blaak 1 sibling, 0 replies; 97+ messages in thread From: Ray Blaak @ 2007-12-15 5:29 UTC (permalink / raw) Robert A Duff <bobduff@shell01.TheWorld.com> writes: > Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes: >> So, when the compiler demands an exception handler, then by golly they >> provide one -- one that simply swallows the exception with a log of >> the stack trace. > > This is what I don't get. I know there are lots of not-so-good > programmers around, but how hard could it be to teach that "junior" > programmer how to do this particular thing right? It's not "rocket > science". ;-) And if the programmer can't learn this much, maybe > they don't have much aptitude for programming in the first place. The problem is that you are being logical :-). For some unexplained reason, this bad practice simply keeps on happening. The only thing I can think of is that the base human instinct is to go "what is the fastest, cheapest way to shut the compiler up?". So, one catches the exception, of course. Now what to do with it? You have to note something useful, after all. Ah! Stack trace! To the log! Done! Forgot to rethrow...whoops... > ... and the senior programmer reviews the code, and gives the junior one > a few tips, and pretty soon ... <oh, never mind> ;-) In the end there is too much energy expended by the senior programmer refighting the same arguments over and over. Eventually a language is chosen where these battles simply become irrelevant. -- Cheers, Bork Bork Ray Blaak rblaaSTRIPCAPS@telus.net ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-13 14:00 ` Exceptions Maciej Sobczak 2007-12-13 14:44 ` Exceptions Robert A Duff @ 2007-12-13 19:29 ` Randy Brukardt 1 sibling, 0 replies; 97+ messages in thread From: Randy Brukardt @ 2007-12-13 19:29 UTC (permalink / raw) "Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message news:9f16235c-260a-460b-873c-2183c154cc0c@e25g2000prg.googlegroups.com... > On 13 Gru, 14:40, Robert A Duff <bobd...@shell01.TheWorld.com> wrote: ... > > I don't consider Constraint_Error "mere", by the way. > > It almost always represents a bug. > > What about a situation when a user entered an input data that was > outside of legal (and documented) range? Or that caused our of range > value further down the pipe? > This is not necessarily a bug, just an indication that the value is > out of range. The exception can help to come back to the input loop > and repeat the user scenario, abandoning all the state that was > created in the meanime. This way the program does not enter into any > abnormal state. An *unhandled* Constraint_Error represents a bug - in this case, a lack of appropriate input validation. One can handle it very locally for that purpose, although I prefer to input values into maximum size objects and check the range with a membership before converting it. (That way, that there is in fact validation is clearer.) Even the propagation of Constraint_Error represents a bug. Exception contracts would help with detecting that, but only if the rules were strong enough that it is possible to write reasonable code that is exception-free. Having Java-style "unchecked exceptions" defeats the purpose. Randy. P.S. Sorry about the old responses just appearing now; something happened to the news server while I was answering those on Monday, and it didn't work again until now. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-09 21:39 ` Exceptions Robert A Duff 2007-12-09 22:13 ` Exceptions Georg Bauhaus @ 2007-12-12 19:18 ` Martin Krischik 2007-12-13 13:27 ` Exceptions Robert A Duff 2007-12-13 23:25 ` Exceptions Ray Blaak 1 sibling, 2 replies; 97+ messages in thread From: Martin Krischik @ 2007-12-12 19:18 UTC (permalink / raw) Robert A Duff wrote: > Why on earth would anybody write "null;" there?! Maybe because Java has no Program_Error. Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-12 19:18 ` Exceptions Martin Krischik @ 2007-12-13 13:27 ` Robert A Duff 2007-12-13 23:25 ` Exceptions Ray Blaak 1 sibling, 0 replies; 97+ messages in thread From: Robert A Duff @ 2007-12-13 13:27 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> writes: > Robert A Duff wrote: > >> Why on earth would anybody write "null;" there?! > > Maybe because Java has no Program_Error. Well, it's as easy to create an unchecked exception in Java as it is in Ada! ;-) - Bob ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-12 19:18 ` Exceptions Martin Krischik 2007-12-13 13:27 ` Exceptions Robert A Duff @ 2007-12-13 23:25 ` Ray Blaak 1 sibling, 0 replies; 97+ messages in thread From: Ray Blaak @ 2007-12-13 23:25 UTC (permalink / raw) Martin Krischik <krischik@users.sourceforge.net> writes: > Robert A Duff wrote: > > > Why on earth would anybody write "null;" there?! > > Maybe because Java has no Program_Error. throw new java.lang.AssertionError("this should be impossible"); -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-06 15:00 Exceptions shaunpatterson 2007-12-06 21:24 ` Exceptions tmoran @ 2007-12-06 21:25 ` Gautier 2007-12-07 4:29 ` Exceptions anon ` (3 subsequent siblings) 5 siblings, 0 replies; 97+ messages in thread From: Gautier @ 2007-12-06 21:25 UTC (permalink / raw) shaunpatterson@gmail.com wrote: > Is there any way to force programmers to catch exception that > your function throws? Something like Java forcing coders to > put try/catch blocks Surely you can do it with AdaControl: http://www.adalog.fr/adacontrol2.htm ______________________________________________________________ Gautier -- http://www.mysunrise.ch/users/gdm/index.htm Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm NB: For a direct answer, e-mail address on the Web site! ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-06 15:00 Exceptions shaunpatterson 2007-12-06 21:24 ` Exceptions tmoran 2007-12-06 21:25 ` Exceptions Gautier @ 2007-12-07 4:29 ` anon 2007-12-07 4:43 ` Exceptions, part 2 anon ` (2 subsequent siblings) 5 siblings, 0 replies; 97+ messages in thread From: anon @ 2007-12-07 4:29 UTC (permalink / raw) with Ada.Text_IO ; use Ada.Text_IO ; procedure p is K : integer ; Test_Error : Exception ; -- -- Returns True if K is Positive -- False if K is Negative -- -- And raises (throw) an exception, if K is Zero -- function F return Boolean is begin If K < 0 then return False ; elsif K > 0 then return True ; else raise Test_Error ; -- (throw) an exception end if ; end F ; begin K := 0 ; if F then Put_Line ( "K is a Positive number" ) ; else Put_Line ( "K is a Negative number" ) ; end if ; exception -- -- catch a program specific exception -- K is Zero. -- when Test_Error => Put_Line ( "K is Zero" ) ; Put_Line ( "So, function raised a exception" ) ; -- -- Catch all other excptions -- when others => Put_Line ( "Program raised a exception" ) ; end p ; In <5947aa62-2547-4fbb-bc46-1111b4a0dcc9@x69g2000hsx.googlegroups.com>, shaunpatterson@gmail.com writes: >Is there any way to force programmers to catch exception that >your function throws? Something like Java forcing coders to >put try/catch blocks > > >Thanks >-- >Shaun ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions, part 2 2007-12-06 15:00 Exceptions shaunpatterson ` (2 preceding siblings ...) 2007-12-07 4:29 ` Exceptions anon @ 2007-12-07 4:43 ` anon 2007-12-07 16:55 ` Exceptions Adam Beneschan 2007-12-08 10:03 ` Exceptions Stephen Leake 5 siblings, 0 replies; 97+ messages in thread From: anon @ 2007-12-07 4:43 UTC (permalink / raw) Forgot, to say there is no GNAT compiler option or standard Ada command that will force a programmer to use the "Exception" statement. So it is up the the programmer to include the statement unlike Java which forces the issue. In <5947aa62-2547-4fbb-bc46-1111b4a0dcc9@x69g2000hsx.googlegroups.com>, shaunpatterson@gmail.com writes: >Is there any way to force programmers to catch exception that >your function throws? Something like Java forcing coders to >put try/catch blocks > > >Thanks >-- >Shaun ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-06 15:00 Exceptions shaunpatterson ` (3 preceding siblings ...) 2007-12-07 4:43 ` Exceptions, part 2 anon @ 2007-12-07 16:55 ` Adam Beneschan 2007-12-07 18:59 ` Exceptions Simon Wright 2007-12-08 10:03 ` Exceptions Stephen Leake 5 siblings, 1 reply; 97+ messages in thread From: Adam Beneschan @ 2007-12-07 16:55 UTC (permalink / raw) On Dec 6, 7:00 am, shaunpatter...@gmail.com wrote: > Is there any way to force programmers to catch exception that > your function throws? Not in Ada. If you're looking for, say, a pragma that you can put on a subprogram declaration to tell the compiler to reject any code that calls the subprogram in a place not governed by an exception handler for a specified exception---that's an interesting idea, and maybe if there's enough interest it could be added to a future revision of Ada, probably Annex H. I don't see any problem with a particular compiler vendor implementing a pragma like that, though, although of course it would be non-portable; perhaps you could ask your vendor if they'd be willing to implement something like that. It would probably not be too difficult to implement. -- Adam ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-07 16:55 ` Exceptions Adam Beneschan @ 2007-12-07 18:59 ` Simon Wright 2007-12-08 0:38 ` Exceptions Adam Beneschan 2007-12-09 21:45 ` Exceptions Robert A Duff 0 siblings, 2 replies; 97+ messages in thread From: Simon Wright @ 2007-12-07 18:59 UTC (permalink / raw) Adam Beneschan <adam@irvine.com> writes: > On Dec 6, 7:00 am, shaunpatter...@gmail.com wrote: >> Is there any way to force programmers to catch exception that >> your function throws? > > Not in Ada. If you're looking for, say, a pragma that you can put > on a subprogram declaration to tell the compiler to reject any code > that calls the subprogram in a place not governed by an exception > handler for a specified exception---that's an interesting idea, and > maybe if there's enough interest it could be added to a future > revision of Ada, probably Annex H. I don't see any problem with a > particular compiler vendor implementing a pragma like that, though, > although of course it would be non-portable; perhaps you could ask > your vendor if they'd be willing to implement something like that. > It would probably not be too difficult to implement. I think this would be a very bad idea. I don't want to be forced to deal with the exception 'here' when it would be better handled by my caller. I suppose we could have 'pragma Propagates' but it seems like a lot of work for little gain (what _is_ the gain?) --S ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-07 18:59 ` Exceptions Simon Wright @ 2007-12-08 0:38 ` Adam Beneschan 2007-12-09 21:45 ` Exceptions Robert A Duff 1 sibling, 0 replies; 97+ messages in thread From: Adam Beneschan @ 2007-12-08 0:38 UTC (permalink / raw) On Dec 7, 10:59 am, Simon Wright <simon.j.wri...@mac.com> wrote: > Adam Beneschan <a...@irvine.com> writes: > > On Dec 6, 7:00 am, shaunpatter...@gmail.com wrote: > >> Is there any way to force programmers to catch exception that > >> your function throws? > > > Not in Ada. If you're looking for, say, a pragma that you can put > > on a subprogram declaration to tell the compiler to reject any code > > that calls the subprogram in a place not governed by an exception > > handler for a specified exception---that's an interesting idea, and > > maybe if there's enough interest it could be added to a future > > revision of Ada, probably Annex H. I don't see any problem with a > > particular compiler vendor implementing a pragma like that, though, > > although of course it would be non-portable; perhaps you could ask > > your vendor if they'd be willing to implement something like that. > > It would probably not be too difficult to implement. > > I think this would be a very bad idea. I don't want to be forced to > deal with the exception 'here' when it would be better handled by my > caller. I wouldn't want that either. But this seems like a "coding standard" sort of thing that organizations sometimes impose to force their less- experienced programmers to be more careful. I know I'd grumble if I had to adhere to a standard like that, but some organizations seem to think it's a good thing anyway. I can see how a pragma like this could be useful in that sort of context. Hopefully the OP is talking about writing a function for internal use by other programmers in the same organization, not one that would be part of a library to be released to the public or for use by customers. If it's either of the last two, then it's definitely a bad idea---it shouldn't be any of his business how other outside users deal with exceptions. Unless, of course, the exception isn't really an exceptional condition but rather a "normal result" returned in a different way, which I think is a really, really bad idea. -- Adam ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-07 18:59 ` Exceptions Simon Wright 2007-12-08 0:38 ` Exceptions Adam Beneschan @ 2007-12-09 21:45 ` Robert A Duff 2007-12-09 22:40 ` Exceptions Georg Bauhaus 1 sibling, 1 reply; 97+ messages in thread From: Robert A Duff @ 2007-12-09 21:45 UTC (permalink / raw) Simon Wright <simon.j.wright@mac.com> writes: > I think this would be a very bad idea. I don't want to be forced to > deal with the exception 'here' when it would be better handled by my > caller. But this would only apply to some exceptions. If you don't want to be "forced", use an unchecked exception. I think there are some mistakes in the Java design for exceptions, but I don't think the whole idea of exception contracts is bad. - Bob ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-09 21:45 ` Exceptions Robert A Duff @ 2007-12-09 22:40 ` Georg Bauhaus 2007-12-10 8:22 ` Exceptions Dmitry A. Kazakov 0 siblings, 1 reply; 97+ messages in thread From: Georg Bauhaus @ 2007-12-09 22:40 UTC (permalink / raw) Robert A Duff wrote: > Simon Wright <simon.j.wright@mac.com> writes: > >> I think this would be a very bad idea. I don't want to be forced to >> deal with the exception 'here' when it would be better handled by my >> caller. > > But this would only apply to some exceptions. If you don't want to be > "forced", use an unchecked exception. > > I think there are some mistakes in the Java design for exceptions, but I > don't think the whole idea of exception contracts is bad. > > - Bob When Robert Dewar talked about exceptions at MIT (I think, that's from memory of a video recording), one of his arguments was that you don't want to write cascades of conditionals for handling return values (being either returned values or failure indicators) ---because that's a mess. Now, when we have a sequence of statements in a block, P1(X); P2(X); ... ; Pn(X, Y); then what will be the average number of exception handlers for this block? Involving how many different exceptions? We would soon arrive at a complicated roughly O(N) size comb of exception choices and Pk-exceptions covered in each handler. Each handler possibly involving conditionals for Pk's and Pj's. I see this as a likely consequence once Ada people start trying to formally cover the exceptional. How would that be an improvement and not just the return code mess again? (And it smells of using state machines to once again try to apply AI to things we didn't think of.) ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-09 22:40 ` Exceptions Georg Bauhaus @ 2007-12-10 8:22 ` Dmitry A. Kazakov 2007-12-10 9:20 ` Exceptions Georg Bauhaus ` (2 more replies) 0 siblings, 3 replies; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-10 8:22 UTC (permalink / raw) On Sun, 09 Dec 2007 23:40:20 +0100, Georg Bauhaus wrote: > Robert A Duff wrote: >> I think there are some mistakes in the Java design for exceptions, but I >> don't think the whole idea of exception contracts is bad. >> > When Robert Dewar talked about exceptions at MIT (I think, that's > from memory of a video recording), one of his arguments was that > you don't want to write cascades of conditionals for handling > return values (being either returned values or failure indicators) > ---because that's a mess. > > Now, when we have a sequence of statements in a block, > > P1(X); P2(X); ... ; Pn(X, Y); > > then what will be the average number of exception handlers > for this block? Involving how many different exceptions? Close to 0. 1. How often do you declare a new exception when writing a new subprogram? My guess is about 1 / 10_000. 2. How often does a caller "eat" an exception of the callee instead of propagating it further? My guess is 1 / 10. There is not that many handlers in a good designed code. This is probably the reason why people forget to handle exceptions properly. They are not that visible. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-10 8:22 ` Exceptions Dmitry A. Kazakov @ 2007-12-10 9:20 ` Georg Bauhaus 2007-12-10 9:30 ` Exceptions Georg Bauhaus 2007-12-10 10:56 ` Exceptions Dmitry A. Kazakov 2007-12-10 12:09 ` Exceptions Niklas Holsti 2007-12-11 2:12 ` Exceptions Randy Brukardt 2 siblings, 2 replies; 97+ messages in thread From: Georg Bauhaus @ 2007-12-10 9:20 UTC (permalink / raw) Dmitry A. Kazakov wrote: >> >> Now, when we have a sequence of statements in a block, >> >> P1(X); P2(X); ... ; Pn(X, Y); >> >> then what will be the average number of exception handlers >> for this block? Involving how many different exceptions? > > Close to 0. > > 1. How often do you declare a new exception when writing a new subprogram? > My guess is about 1 / 10_000. OK, assume programmers will declare new exceptions only for 1 / 10_000 subprograms. procedure P1(X: Temperature) raise Constraint_Error; procedure P5(X: Pressure) raise Constraint_Error; begin P1(Hot); P5(Deflated); exception when Constraint_Error => ? end; Do programmers put a block around every procedure call so that the proper occurence of Constraint_Error is handled? And will this likelyhood increase once subp declarations announce foreseeable exceptions? > 2. How often does a caller "eat" an exception of the callee instead of > propagating it further? My guess is 1 / 10. Are you assuming current rules for guessing 10% exception handling, i.e., no exceptions are announced by the subprogram declaration? > There is not that many handlers in a good designed code. Hear, hear. [Q] Why do we need more exception announcements, then? Will design improve because of subp with exception announcements? > This is probably > the reason why people forget to handle exceptions properly. They are not > that visible. If programmers do not handle exceptions properly when they do not see them in source, will forcing them to handle exceptions make them handle exceptions _properly_? I have seen a number of null handlers... My guess is that missing else branches or undocumented null "others" in case distinctions are a related issue. The issue really is handling cases, not announcing them. Every if implies the possibility of an else. Still we can have null else branches (or "others" choises). If only the Algol symbol "comment" had been given more emphasis in successor languages. A friendly tell-us-what-you-think! mechanism is better IMHO than a combination of force together with a force absorbing mechanism! (Exception "contracts" together with null handlers and the like.) case Traffic_Light is when Red => ... ; when Green => .... ; when others => comment No comment; null; -- forces the comment. -- Hypothesis: the comment "No comment" will not -- pass quality control end case; Remove "others" from the languge? :-) ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-10 9:20 ` Exceptions Georg Bauhaus @ 2007-12-10 9:30 ` Georg Bauhaus 2007-12-10 10:56 ` Exceptions Dmitry A. Kazakov 1 sibling, 0 replies; 97+ messages in thread From: Georg Bauhaus @ 2007-12-10 9:30 UTC (permalink / raw) Georg Bauhaus wrote: > case Traffic_Light is > when Red => ... ; > when Green => .... ; > when others => comment "No comment"; > null; -- forces the comment. > -- Hypothesis: the comment "No comment" will not > -- pass quality control I forgot the important part: the "comment" keyword will have the desired effect of uncovering information to the team. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-10 9:20 ` Exceptions Georg Bauhaus 2007-12-10 9:30 ` Exceptions Georg Bauhaus @ 2007-12-10 10:56 ` Dmitry A. Kazakov 2007-12-11 2:18 ` Exceptions Randy Brukardt 2007-12-11 8:19 ` Exceptions Georg Bauhaus 1 sibling, 2 replies; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-10 10:56 UTC (permalink / raw) On Mon, 10 Dec 2007 10:20:38 +0100, Georg Bauhaus wrote: > Do programmers put a block around every procedure call so > that the proper occurence of Constraint_Error is handled? Yes if Constraint_Error shall not propagate further. What is the alternative BTW? To say that it does not propagate, but let it do? Note that to argue against exception contracts on the basis that handling exceptions is difficult is a fallacy. It is like to argue that floating-point type is bad because calculating sine is difficult. > And will this likelyhood increase once subp declarations > announce foreseeable exceptions? > >> 2. How often does a caller "eat" an exception of the callee instead of >> propagating it further? My guess is 1 / 10. > > Are you assuming current rules for guessing 10% exception handling, > i.e., no exceptions are announced by the subprogram declaration? I meant that an exception is typically propagated out of 10 scopes before it gets handled. >> There is not that many handlers in a good designed code. > > Hear, hear. [Q] Why do we need more exception announcements, then? Because of the damage an unhandled exception does. The goal of software design is to minimize the damage caused by program execution (the best way is not to write any programs at all (:-)). Lesser likelihood of exception propagation is compensated by the damage inflicted by. > Will design improve because of subp with exception announcements? This is a different question. Clearly any language change has certain effect on the programming practices and average design. I cannot foresee how contracts would influence us, programmers. I can only say that contracted exceptions are well in Ada spirit. >> This is probably >> the reason why people forget to handle exceptions properly. They are not >> that visible. > > If programmers do not handle exceptions properly when they > do not see them in source, will forcing them to handle exceptions > make them handle exceptions _properly_? Exactly so. They still will have an option to keep on ignoring exceptions. Only if they will announce the program as exception E free, only then, they will be forced to take care of E. Looks reasonable to me. > I have seen a number of null handlers... > > My guess is that missing else branches or undocumented null "others" > in case distinctions are a related issue. The issue really is > handling cases, not announcing them. Every if implies the possibility > of an else. Still we can have null else branches (or "others" choises). No, only in absence of a contract. Consider: function Foo return ... is begin if ... then return ...; end if; end Foo; This is illegal because of the contract to return a value. I hope you do not propose to make Foo legal because required "else" would spoil so nicely formatted code? (:-)) Exception non-propagation contracts fall under this category. > If only the Algol symbol "comment" had been given more emphasis > in successor languages. A friendly tell-us-what-you-think! > mechanism is better IMHO than a combination of force together with a > force absorbing mechanism! (Exception "contracts" together with > null handlers and the like.) > > case Traffic_Light is > when Red => ... ; > when Green => .... ; > when others => > comment No comment; > null; -- forces the comment. > -- Hypothesis: the comment "No comment" will not > -- pass quality control > end case; > > Remove "others" from the languge? :-) The problem here is not others. The problem is the power of a language construct. Others is harmless if it includes only Blue. It can be damaging if it does "all other Integers." Ideally the constructs should be as weak as possible to be able to accomplish the goal. Goto or template solve the problem but they call the devil who won't go back. So "others" does when it refers to a set of big cardinality then covered by null-action. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-10 10:56 ` Exceptions Dmitry A. Kazakov @ 2007-12-11 2:18 ` Randy Brukardt 2007-12-11 8:19 ` Exceptions Georg Bauhaus 1 sibling, 0 replies; 97+ messages in thread From: Randy Brukardt @ 2007-12-11 2:18 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:194zh0rz03487$.6vxhavjdbpdr.dlg@40tude.net... ... > No, only in absence of a contract. Consider: > > function Foo return ... is > begin > if ... then > return ...; > end if; > end Foo; > > This is illegal because of the contract to return a value. I hope you do > not propose to make Foo legal because required "else" would spoil so nicely > formatted code? (:-)) Actually, this is perfectly legal because there is a value returned, and Ada doesn't require any sort of path analysis (it is impossible in the general case). It does raise Program_Error, but that is very different. Especially since you are talking about static contracts... Randy. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-10 10:56 ` Exceptions Dmitry A. Kazakov 2007-12-11 2:18 ` Exceptions Randy Brukardt @ 2007-12-11 8:19 ` Georg Bauhaus 2007-12-11 11:55 ` Exceptions Dmitry A. Kazakov 1 sibling, 1 reply; 97+ messages in thread From: Georg Bauhaus @ 2007-12-11 8:19 UTC (permalink / raw) Dmitry A. Kazakov wrote: In my view, a language feature is useful if and only if it actually helps reducing the number of bugs. >>> 2. How often does a caller "eat" an exception of the callee instead of >>> propagating it further? My guess is 1 / 10. >> Are you assuming current rules for guessing 10% exception handling, >> i.e., no exceptions are announced by the subprogram declaration? > > I meant that an exception is typically propagated out of 10 scopes before > it gets handled. And? I/O should be counted separately; Using exceptions to signal invalid input to some procedure way up the call stack is indeed not a good idea; in fact, DbC warns you that DbC is not at all about invalid input. >>> There is not that many handlers in a good designed code. >> Hear, hear. [Q] Why do we need more exception announcements, then? > > Because of the damage an unhandled exception does. I don't buy this. Sure, if your program has effects when it continues computing using erroneous values, it may damage things; but this case seems contrued like its counterpart: that in S1; S2;, S1 fails. This failure need not have an effect on S2! >> Will design improve because of subp with exception announcements? > > This is a different question. Clearly any language change has certain > effect on the programming practices and average design. I cannot foresee > how contracts would influence us, programmers. The question, 'How does a language feature affect programs?' is all that matters because programs are produced by writing them in the programming language with a certain set of features. > I can only say that > contracted exceptions are well in Ada spirit. Recently, I've read here on c.l.ada that there is Ada and Ada in the presence of exceptions... >> If programmers do not handle exceptions properly when they >> do not see them in source, will forcing them to handle exceptions >> make them handle exceptions _properly_? > > Exactly so. They still will have an option to keep on ignoring exceptions. > Only if they will announce the program as exception E free, only then, they > will be forced to take care of E. Looks reasonable to me. I suggest you look at some Java code, then. It might change your perspective on programming (not necessarily Java's fault). >> If only the Algol symbol "comment" had been given more emphasis >> in successor languages. A friendly tell-us-what-you-think! >> mechanism is better IMHO than a combination of force together with a >> force absorbing mechanism! (Exception "contracts" together with >> null handlers and the like.) >> >> case Traffic_Light is >> when Red => ... ; >> when Green => .... ; >> when others => >> comment No comment; >> null; -- forces the comment. >> -- Hypothesis: the comment "No comment" will not >> -- pass quality control >> end case; >> >> Remove "others" from the languge? :-) > > The problem here is not others. The problem is the power of a language > construct. Again, the construct gets its effective power from the programmer who uses it. It does not matter that you _can_ "write Fortran in any language"; what _will_ non-theorist programmers actually do? Therefore, a construct should be such that typical use of the construct will help normal programmers writing reasonably good programs. (For me this includes being able to understand and change the program without a PhD in CS.) Here is an example of why I think that treating exceptions like another formal "flow" of control is not going to work in any practical sense. packge Subsys is Oops: exception; -- minor hickup Argh: exception; -- Can't go on An_Error_Has_Occured: exception; type S is tagged null record; -- parent Null_S: constant S; end Subsys; package Subsys.P is type T is new S with null record; function F(X: in out T) return T raise Argh; end Subsys.P; package Subsys.Q is type T is new S with null record; procedure G(X: in out T) return T raise Oops; end Subsys.P; with Subsys; procedure Job raise Subsys.An_Error_Has_Occured; -- client with Subsys.P, Subsys.Q; procedure Job is use Subsys; begin L: declare Result : S'class := Q.G(P.F(Null_S)); -- HERE begin -- ... actions null; end L; exception when Oops => -- Oops is o.K., our software is robust null; when Argh => raise An_Error_Has_Occured; end Subsys.Job; Now the programmers writing Subsys.P and Subsys.Q decide to switch the exceptions raised by F and G respectively. There is a chance that Job won't need a different handler because the set of exceptions to be handled has not changed: {Oops, Argh}. But the meaning of the exceptions has changed significantly, Oops is now the exception that must be handled but it isn't ... I don't see an improvement so far. So we need a different program! One that enables the compiler to notice that the exception announcements have been changed. with Subsys.P, Subsys.Q; procedure Job_Alt is use Subsys; begin -- Split Q.G(P.F(Null_S)); into constituent parts -- so that the compiler can differentiate by exception Handle_G_Exception: declare F_Result : S'class := P.F(Null_S); begin L: declare G_Result : S'class := Q.G(F_Result); begin -- ... actions null; end L; exception when Oops => raise An_Error_Has_Occured; end Handle_G_Exception; exception -- occurence likely raised by P.F when Argh => -- Oops (refactoring missed the name change) -- is o.K., our software is robust null; end Job_Alt; If this style becomes customary for the proper handling of Q.G(P.F(Null_S)); then I'm not sure that announcing exceptions alone is that useful a language change. The example given makes me assume that the increase in SLOC count is opening doors to another row of error candidates. The requires/modifies/ensures model seems more practical to me. It doesn't force handling exceptions; still many programmers using that model seem to be writing preconditions at least. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-11 8:19 ` Exceptions Georg Bauhaus @ 2007-12-11 11:55 ` Dmitry A. Kazakov 2007-12-11 16:13 ` Exceptions Georg Bauhaus 0 siblings, 1 reply; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-11 11:55 UTC (permalink / raw) On Tue, 11 Dec 2007 09:19:37 +0100, Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: > > In my view, a language feature is useful if and only if it > actually helps reducing the number of bugs. > >>>> 2. How often does a caller "eat" an exception of the callee instead of >>>> propagating it further? My guess is 1 / 10. >>> Are you assuming current rules for guessing 10% exception handling, >>> i.e., no exceptions are announced by the subprogram declaration? >> >> I meant that an exception is typically propagated out of 10 scopes before >> it gets handled. > > And? So you do not need to place any handlers in 9/10 subprograms. > I/O should be counted separately; Using exceptions to signal invalid > input to some procedure way up the call stack is indeed not a good > idea; Why? It is the sole idea of exception, to postpone handling until reaching a context where there were more knowledge available. > in fact, DbC warns you that DbC is not at all about invalid > input. Maybe, but as I have explained in my post to Randy, don't want to be get involved into semantic issues. Those are not my concern. The contracts I meant will tell nothing about the semantics. They will do merely about a *possibility* for an exception to propagate. Nothing more. >>>> There is not that many handlers in a good designed code. >>> Hear, hear. [Q] Why do we need more exception announcements, then? >> >> Because of the damage an unhandled exception does. > > I don't buy this. Sure, if your program has effects when > it continues computing using erroneous values, I does not continue, it crashes! >>> Will design improve because of subp with exception announcements? >> >> This is a different question. Clearly any language change has certain >> effect on the programming practices and average design. I cannot foresee >> how contracts would influence us, programmers. > > The question, 'How does a language feature affect programs?' > is all that matters because programs are produced by writing > them in the programming language with a certain set of features. If you want an answer to this question, then in my humble opinion contracted exceptions will sufficiently improve quality of Ada programs. You are welcome to disagree. >>> If programmers do not handle exceptions properly when they >>> do not see them in source, will forcing them to handle exceptions >>> make them handle exceptions _properly_? >> >> Exactly so. They still will have an option to keep on ignoring exceptions. >> Only if they will announce the program as exception E free, only then, they >> will be forced to take care of E. Looks reasonable to me. > > I suggest you look at some Java code, then. It might change > your perspective on programming (not necessarily Java's fault). We should learn from mistakes and successes of others... > Therefore, a construct should be such that typical use of the > construct will help normal programmers writing reasonably good > programs. (For me this includes being able to understand and change > the program without a PhD in CS.) Agreed. > Here is an example of why I think that treating exceptions > like another formal "flow" of control is not going to work > in any practical sense. > > packge Subsys is > > Oops: exception; -- minor hickup > Argh: exception; -- Can't go on ... > exception > when Oops => > -- Oops is o.K., our software is robust > null; > when Argh => > raise An_Error_Has_Occured; > end Subsys.Job; > > Now the programmers writing Subsys.P and Subsys.Q decide to > switch the exceptions raised by F and G respectively. > There is a chance that Job won't need a different handler > because the set of exceptions to be handled > has not changed: {Oops, Argh}. > But the meaning of the exceptions has changed significantly, > Oops is now the exception that must be handled but it isn't ... > > I don't see an improvement so far. 1. It is *not* about semantics of exceptions, see above. 2. The program design above (in my view) is fundamentally flawed, because exceptions are for programming, they are not for debugging. > So we need a different program! One that enables the compiler > to notice that the exception announcements have been changed. What for, if the handling is still same? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-11 11:55 ` Exceptions Dmitry A. Kazakov @ 2007-12-11 16:13 ` Georg Bauhaus 2007-12-12 11:18 ` Exceptions Dmitry A. Kazakov 0 siblings, 1 reply; 97+ messages in thread From: Georg Bauhaus @ 2007-12-11 16:13 UTC (permalink / raw) Dmitry A. Kazakov schrieb: > 1. It is *not* about semantics of exceptions, see above. > > 2. The program design above (in my view) is fundamentally flawed, because > exceptions are for programming, they are not for debugging. OK, I beg to differ. Exceptions (starting with their very name) should not be (mis)used for signalling information IMHO. Ada has better tools for sending messages, or for information passing. >> So we need a different program! One that enables the compiler >> to notice that the exception announcements have been changed. > > What for, if the handling is still same? The exceptions have been switched so handling must make a corresponding switch, but there is no way to notice this at the client side (F(G(X)). Which was the point. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-11 16:13 ` Exceptions Georg Bauhaus @ 2007-12-12 11:18 ` Dmitry A. Kazakov 0 siblings, 0 replies; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-12 11:18 UTC (permalink / raw) On Tue, 11 Dec 2007 17:13:28 +0100, Georg Bauhaus wrote: > Dmitry A. Kazakov schrieb: > >> 1. It is *not* about semantics of exceptions, see above. >> >> 2. The program design above (in my view) is fundamentally flawed, because >> exceptions are for programming, they are not for debugging. > > OK, I beg to differ. Exceptions (starting with their very name) > should not be (mis)used for signalling information IMHO. Ada has > better tools for sending messages, or for information passing. This is wrong in many aspects: A. Exceptions are more about flow control than passing data. Message sending would an inappropriate abstraction here, for many reasons. B. An exception signals the program state change. The name of means that the new state is somewhat exceptional, in the sense that it is not desired, not so common. But it is still a legal state. Bug is *no* state. C. Exceptions as a programming language construct, per definition, are for programming (software design). Debugging is not programming. (I hope you aren't going to propose a "bug-driven software design paradigm" (:-)) >>> So we need a different program! One that enables the compiler >>> to notice that the exception announcements have been changed. >> >> What for, if the handling is still same? > > The exceptions have been switched so handling must make > a corresponding switch, If you want to deal with program correctness (semantics) then there should be other tools, like SPARK. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-10 8:22 ` Exceptions Dmitry A. Kazakov 2007-12-10 9:20 ` Exceptions Georg Bauhaus @ 2007-12-10 12:09 ` Niklas Holsti 2007-12-10 13:08 ` Exceptions Dmitry A. Kazakov 2007-12-11 2:12 ` Exceptions Randy Brukardt 2 siblings, 1 reply; 97+ messages in thread From: Niklas Holsti @ 2007-12-10 12:09 UTC (permalink / raw) Dmitry A. Kazakov wrote: > [some questions, see below] I'm not sure if Dmitry really wants answers to his questions below -- perhaps they were merely rhetorical -- but they tickled my curiosity, so here is one data point from my main Ada application: Number of packages (.ads files) : 196 Number of package bodies (.adb files) : 147 Total source lines (including blanks and comments): 201_731 Total number of lines with semicolons : 42_935 Total number of subprograms : 6_292 Exceptions declared : 87 Explicit raise statements (with exception name) : 239 - of Constraint_Error (note 1) : 20 - of Program_Error (note 1) : 12 - of application-defined exceptions : 207 Exception-handler sequences (note 2) : 219 Exception handlers (note 3) : 275 Handlers that "eat "exceptions (note 4) : 180 - eat specific application-defined exception(s) : 129 - eat specific language-defined exception(s) : 34 - eat "others" : 17 Handlers that raise or re-raise exceptions : 102 - propagate same application-defined exception : 13 - propagate same language-defined exception : 22 - propagate same "others" exception : 28 - change app-def. exc. to other app-def. exc. : 20 - change language-def. exc. to app-def. exc. : 18 - change app-def. exc. to language-def. exc. : 1 Notes: 1. Of the language-defined exceptions, only Constraint_Error and Program_Error are raised explicitly (by "raise <name>"). 2. An "exception-handler sequence" is the list of exception_handlers at the end of a handled_- sequence_of_statements. 3. Whether for one exception, several exceptions, or "others". 4. Handlers that do not contain "raise" statements. Some of the above was counted by hand from "grep" outputs, so the numbers may be off by a couple of units. It is noteworthy that most exception-handler sequences (total: 219) only have one exception handler (total: 275), although this single handler often handles several exceptions, or "others". > 1. How often do you declare a new exception when writing a new subprogram? > My guess is about 1 / 10_000. From the numbers above: 87 / 6_292 = 138 / 10_000. In some cases one declared exception can be raised in several subprograms, but I think the average number of subprograms that can raise a given application-defined exception is between 1 and 2, not larger, in this application. > 2. How often does a caller "eat" an exception of the callee instead of > propagating it further? My guess is 1 / 10. My numbers do not separate between exceptions propagated from calls and exceptions raised within the handled sequence-of-statements itself. But my feeling is that at least half of the handlers are meant to catch exception from calls, and I don't think that there is any systematic difference in the proportion of "eaters" versus "propagators" between the two cases. So, from the above numbers, "eaters" / "all handlers" = 180 / 275 = 6.5 / 10. > There is not that many handlers in a good designed code. That is too generalized. I think that the number of handlers is partly a matter of personal style (preference for error-code parameters vs exceptions) and partly depends on the required level of error tolerance (ability to continue processing in spite of errors). Good error tolerance may require more local handlers to clean up local state, before (possibly) passing the exception to higher levels. The application behind the numbers given above is not required to be error-tolerant. Thus, many exceptions can simply be propagated to a high level, without passing through many local clean-up handlers on the way. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-10 12:09 ` Exceptions Niklas Holsti @ 2007-12-10 13:08 ` Dmitry A. Kazakov 2007-12-10 20:02 ` Exceptions Niklas Holsti 0 siblings, 1 reply; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-10 13:08 UTC (permalink / raw) On Mon, 10 Dec 2007 14:09:31 +0200, Niklas Holsti wrote: > Dmitry A. Kazakov wrote: > > > [some questions, see below] > > I'm not sure if Dmitry really wants answers to his questions below > -- perhaps they were merely rhetorical -- but they tickled my > curiosity, so here is one data point from my main Ada application: Thank you for the figures. It is really interesting. >> 1. How often do you declare a new exception when writing a new subprogram? >> My guess is about 1 / 10_000. > > From the numbers above: 87 / 6_292 = 138 / 10_000. One per hundred also. As for me I tend to reuse IO_Exceptions if semantics is close, so my figure should be much lesser. > In some cases > one declared exception can be raised in several subprograms, but I > think the average number of subprograms that can raise a given > application-defined exception is between 1 and 2, not larger, in > this application. This is a very low figure. But as I said, I reuse exceptions much. A possible danger is to overload an exception too much (like Constraint_Error already is). This is IMO a question of custom and also of the language design. When exceptions tend to propagate out of the application, one would certainly like to make them "meaningful" indicating the fault reason as precise as possible. This is not what I wanted from Ada. I'd like to have all exceptions handled. So I treat them rather as signals within and for the application. I don't buy exceptions as a debugging tool. >> 2. How often does a caller "eat" an exception of the callee instead of >> propagating it further? My guess is 1 / 10. > > My numbers do not separate between exceptions propagated from calls > and exceptions raised within the handled sequence-of-statements > itself. But my feeling is that at least half of the handlers are > meant to catch exception from calls, and I don't think that there > is any systematic difference in the proportion of "eaters" versus > "propagators" between the two cases. > > So, from the above numbers, "eaters" / "all handlers" = 180 / 275 = > 6.5 / 10. Interesting. I didn't measured my code, but I expect more scopes where exceptions propagate unhandled. That depends on how much refactoring is done. Actually, I have an impression that many exception-related bugs appear while code refactoring and other small apparently equivalent code modifications, which in turn are not almost equivalent. >> There is not that many handlers in a good designed code. > > That is too generalized. I think that the number of handlers is > partly a matter of personal style (preference for error-code > parameters vs exceptions) and partly depends on the required level > of error tolerance (ability to continue processing in spite of > errors). Yes > Good error tolerance may require more local handlers to > clean up local state, before (possibly) passing the exception to > higher levels. Possibly, however there is a concurring mechanism for clean-ups, I mean controlled types. In many cases Finalize does what otherwise a handler would. > The application behind the numbers given above is not required to > be error-tolerant. Thus, many exceptions can simply be propagated > to a high level, without passing through many local clean-up > handlers on the way. Yes, but again it is probably not about being error-[in]tolerant. I think the overall code structure plays a role here. When I refactor small subprogram doing this or that thing, I often leave exception handling functionality to another piece of code. Maybe this is my personal motivation behind longing for contracted exceptions. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-10 13:08 ` Exceptions Dmitry A. Kazakov @ 2007-12-10 20:02 ` Niklas Holsti 2007-12-11 12:31 ` Exceptions Dmitry A. Kazakov 0 siblings, 1 reply; 97+ messages in thread From: Niklas Holsti @ 2007-12-10 20:02 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Mon, 10 Dec 2007 14:09:31 +0200, Niklas Holsti wrote: > > >>Dmitry A. Kazakov wrote: >> >> > [some questions, see below] >> >>I'm not sure if Dmitry really wants answers to his questions below >>-- perhaps they were merely rhetorical -- but they tickled my >>curiosity, so here is one data point from my main Ada application: > > > Thank you for the figures. It is really interesting. > > >>>1. How often do you declare a new exception when writing a new subprogram? >>>My guess is about 1 / 10_000. >> >> From the numbers above: 87 / 6_292 = 138 / 10_000. > > > One per hundred also. As for me I tend to reuse IO_Exceptions if semantics > is close, so my figure should be much lesser. The only language-defined exceptions that are thusly "reused" in this application are Constraint_Error (mainly used in container structures that have some notion of "indexing" or "keyed look-up" where C_E is used to report an invalid index or key) and Program_Error (to kill the application when its state is screwed up in a way that indicates a programming error rather than an input error or user error). One reason for the large number of application-defined exceptions in this application may be that it uses a lot of functional-style programming with functions that return objects with run-time constraints (eg. unconstrained array types). Such functions cannot easily use error codes and must use exceptions to signal problems. >>In some cases >>one declared exception can be raised in several subprograms, but I >>think the average number of subprograms that can raise a given >>application-defined exception is between 1 and 2, not larger, in >>this application. > > This is a very low figure. It is my estimate for the *average* number of subprograms that contain raise statements for a given application-defined exception. There are certainly *some* exceptions that are raised in 5..10 subprograms. The number of subprograms that can *propagate* a given application-defined exception (from their callees) is larger, but I can't say by how much. Clearly most subprograms have no exception handlers at all and thus propagate all exceptions raised in them or in their callees. > But as I said, I reuse exceptions much. A > possible danger is to overload an exception too much (like Constraint_Error > already is). Agreed. Whenever this application explicitly raises Constraint_Error it is (or should be) handled a few (1 .. 3) levels higher in the call path. Several handlers for Constraint_Error (whether raised explicitly or by standard run-time checks) "translate" C_E to a more specific exception by raising the specific application-defined exception for handling at higher levels. > This is IMO a question of custom and also of the language design. When > exceptions tend to propagate out of the application, one would certainly > like to make them "meaningful" indicating the fault reason as precise as > possible. Yes, but whatever one does, an exception occurrence is almost never meaningful for the user, only for the developer. > This is not what I wanted from Ada. I'd like to have all > exceptions handled. So I treat them rather as signals within and for the > application. If I can foresee a situation that can cause a certain exception, of course I put in a handler. The problem is programming errors or input errors that I do not foresee. For such I still rely on catch-all handlers at certain levels and ask the user to send me the error messages that these handlers emit. > I don't buy exceptions as a debugging tool. Exceptions (even when unhandled) are an essential part of my debugging kit, but of course not the only part. In the application under discussion an unhandled (or "others" handled) exception typically only indicates the presence of a programming error, not its location or its nature. For the rest, I tend to use programmed internal checks and action/state traces that can be turned on with specific command-line options. I rarely use a real debugger. >>>2. How often does a caller "eat" an exception of the callee instead of >>>propagating it further? My guess is 1 / 10. >> >>My numbers do not separate between exceptions propagated from calls >>and exceptions raised within the handled sequence-of-statements >>itself. But my feeling is that at least half of the handlers are >>meant to catch exception from calls, and I don't think that there >>is any systematic difference in the proportion of "eaters" versus >>"propagators" between the two cases. >> >>So, from the above numbers, "eaters" / "all handlers" = 180 / 275 = >> 6.5 / 10. > > > Interesting. I didn't measured my code, but I expect more scopes where > exceptions propagate unhandled. Sure, I was just comparing *handlers* that "eat" versus handlers that "propagate". Most subprograms have no handlers and propagate all exceptions. In another post, you (Dmitry) say that your question (2) meant the number of call levels over which an exception usually propagates before being handled -- the "distance" between the raise point and the handler. I haven't measured that for my application, but my feeling is that there are two kinds of exception (occurrences): the non-fatal ones and the fatal or semi-fatal ones. For a non-fatal exception the application takes some corrective action, for example throws away some small unit of data or increases the size of a container structure, and then continues processing. In this application the raise-to-handle distance for such exceptions is small, 1..3 levels I would say. For a fatal or semi-fatal exception this application either stops completely or skips a major part of its input and continues with the remaining parts. Here the raise-to-handle distance is large and the handler is often an "others" handler. > That depends on how much refactoring is > done. Actually, I have an impression that many exception-related bugs > appear while code refactoring and other small apparently equivalent code > modifications, which in turn are not almost equivalent. This app has had only a handful of exception-related bugs, most coming from null accesses, a couple from overflows (the app handles machine-level binary numbers of various sizes). I can't say if they are related to refactoring of any sort. >>Good error tolerance may require more local handlers to >>clean up local state, before (possibly) passing the exception to >>higher levels. > > Possibly, however there is a concurring mechanism for clean-ups, I mean > controlled types. In many cases Finalize does what otherwise a handler > would. True. This app was started when Ada 95 was young, and we were a bit afraid of compiler bugs in controlled types, so almost no controlled types are used (Unbounded_String is used in several places, though). >>The application behind the numbers given above is not required to >>be error-tolerant. Thus, many exceptions can simply be propagated >>to a high level, without passing through many local clean-up >>handlers on the way. (Commenting on my own text above: these are the "fatal or semi-fatal" exceptions.) > Yes, but again it is probably not about being error-[in]tolerant. I think > the overall code structure plays a role here. When I refactor small > subprogram doing this or that thing, I often leave exception handling > functionality to another piece of code. Maybe this is my personal > motivation behind longing for contracted exceptions. The main problem I see in contracted exceptions is the problem with layered architectures where some intermediate layers are general/generic and not application-specific. For example, a generic tree-traversal (intermediate) layer may have to propagate application-defined exceptions from the application-specific "action" routines in a lower layer, to the application's handlers in a higher layer. I don't see how to do that easily with explicit exception contracts. It may be easier in a language with exception classes that can be derived into exception subclasses that have application-defined occurrence-specific data components. The intermediate layer could define its own exception class(es) for such propagated exceptions and the application would define subclass(es) with application-specific information. The contract of the intermediate layer could the list the exception class(es), not the subclass(es). -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-10 20:02 ` Exceptions Niklas Holsti @ 2007-12-11 12:31 ` Dmitry A. Kazakov 2007-12-11 13:21 ` Exceptions Niklas Holsti 0 siblings, 1 reply; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-11 12:31 UTC (permalink / raw) On Mon, 10 Dec 2007 22:02:55 +0200, Niklas Holsti wrote: > One reason for the large number of application-defined exceptions > in this application may be that it uses a lot of functional-style > programming with functions that return objects with run-time > constraints (eg. unconstrained array types). Such functions cannot > easily use error codes and must use exceptions to signal problems. I tend use End_Error, Use_Error, Data_Error in such cases. The question is how many different exceptions may propagate from a set of closures used in one context. Not that many, so my guess is that one need not so many different exceptions. > Clearly most subprograms have no exception > handlers at all and thus propagate all exceptions raised in them or > in their callees. Yes, this why I don't believe in the argument of abundant exception handlers spoiling each and other program block. I don't see why contracts should change anything here. >> This is IMO a question of custom and also of the language design. When >> exceptions tend to propagate out of the application, one would certainly >> like to make them "meaningful" indicating the fault reason as precise as >> possible. > > Yes, but whatever one does, an exception occurrence is almost never > meaningful for the user, only for the developer. Right. >> This is not what I wanted from Ada. I'd like to have all >> exceptions handled. So I treat them rather as signals within and for the >> application. > > If I can foresee a situation that can cause a certain exception, of > course I put in a handler. The problem is programming errors or > input errors that I do not foresee. For such I still rely on > catch-all handlers at certain levels and ask the user to send me > the error messages that these handlers emit. Which is one of the advantages of the contracted model. A typical scenario: A lazy (let's say busy) programmer designs some set of low-level primitives raising some exceptions. Then he starts to write a middle layer that reuses those primitives, not necessarily in exactly this order, but anyway. The exceptions of the middle layer are different, and of course, the lower level exceptions do not propagate out the middle layer. At this point he has already forgot most of when and what the lower level raises. He remembers the exceptions E3 and E10, but the rest is vanished. He decides whether to use "when others" but has no clear idea what to do there, so maybe he places something looking more or less appropriate there hoping that the debugging phase will shed more light on the issue, or just drop it, depending on how much coffee he already had. The rest is obvious. Does it sound familiar? Now a contracted exceptions scenario: The programmer contracts a middle-layer subprogram as non-propagating anything he does not want to. He does not write any handlers, just compiles the code. The compiler complains about E1. Aha - he says, where that E1 comes from? This repeats until all low-level exceptions are caught, *understood* and handled. > The main problem I see in contracted exceptions is the problem with > layered architectures where some intermediate layers are > general/generic and not application-specific. For example, a > generic tree-traversal (intermediate) layer may have to propagate > application-defined exceptions from the application-specific > "action" routines in a lower layer, to the application's handlers > in a higher layer. I don't see how to do that easily with explicit > exception contracts. It may be easier in a language with exception > classes that can be derived into exception subclasses that have > application-defined occurrence-specific data components. The > intermediate layer could define its own exception class(es) for > such propagated exceptions and the application would define > subclass(es) with application-specific information. The contract of > the intermediate layer could the list the exception class(es), not > the subclass(es). I think there is no simple answer to this. What could help IMO is: 1. Conditional exception contracts (for things like Storage_Error and exceptions from the closures) 2. Inheritable exception contracts (to be able to refer to a group of exceptions from another subprogram) 3. Making exceptions an ordered type with some kind of tree-like distance. 4. Renaming/delegation of exceptions. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-11 12:31 ` Exceptions Dmitry A. Kazakov @ 2007-12-11 13:21 ` Niklas Holsti 2007-12-12 0:01 ` Exceptions Randy Brukardt 2007-12-12 11:00 ` Exceptions Dmitry A. Kazakov 0 siblings, 2 replies; 97+ messages in thread From: Niklas Holsti @ 2007-12-11 13:21 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Mon, 10 Dec 2007 22:02:55 +0200, Niklas Holsti wrote: > >>One reason for the large number of application-defined exceptions >>in this application may be that it uses a lot of functional-style >>programming with functions that return objects with run-time >>constraints (eg. unconstrained array types). Such functions cannot >>easily use error codes and must use exceptions to signal problems. > > I tend use End_Error, Use_Error, Data_Error in such cases. I don't like that at all, because in my mind End_Error etc. are associated with Ada IO, not with my application -- their meaning (semantics :-) is not appropriate, and I don't want to be Humpty Dumpty and make them mean what I want them to mean. Of course, if the function in question actually is reading a file, and fails because the file ends at an unexpected point, then End_Error could be appropriate. But for a function that has no connection with IO I would never "reuse" End_Error just to avoid declaring a specific exception. > The question is > how many different exceptions may propagate from a set of closures used in > one context. Not that many, so my guess is that one need not so many > different exceptions. But surely one of the main points of a contract is to show what a caller may have to do, to handle the propagated exceptions. To "overload" one exception (such as End_Error) with many different meanings, perhaps requiring different handling, would make the caller's job difficult. I agree that the number of different exceptions that are usefully propagated from most subprograms is generally small, because the caller does not have enough understanding of the possible exceptional situtations in the callee to be able to handle many different exceptions in specific ways. >>Clearly most subprograms have no exception >>handlers at all and thus propagate all exceptions raised in them or >>in their callees. > > Yes, this why I don't believe in the argument of abundant exception > handlers spoiling each and other program block. I don't see why contracts > should change anything here. I think all subprograms would need contracts (to specify the possibly propagated exceptions), not just the few subprograms that have exception handlers. The contract has to be in the subprogram declaration, while the presence or absence of exception handlers is a property of the body. Exception contracts could become a considerable part of the source code, especially if they would have to include the "always possible" exceptions like Storage_Error and in the absence of any SPARK-like analysis to exclude impossible exceptions from the contract. > A typical scenario: A lazy (let's say busy) programmer designs some set of > low-level primitives raising some exceptions. Then he starts to write a > middle layer that reuses those primitives, not necessarily in exactly this > order, but anyway. The exceptions of the middle layer are different, and of > course, the lower level exceptions do not propagate out the middle layer. > At this point he has already forgot most of when and what the lower level > raises. He remembers the exceptions E3 and E10, but the rest is vanished. > He decides whether to use "when others" but has no clear idea what to do > there, so maybe he places something looking more or less appropriate there > hoping that the debugging phase will shed more light on the issue, or just > drop it, depending on how much coffee he already had. The rest is obvious. > Does it sound familiar? Not really. I use informal exception contracts (in comments describing each and every subprogram), so I have not experienced that kind of mess. But I have mistakenly omitted a necessary handler once or twice, generally when the raise-to-handle distance has been very large (fatal or semi-fatal exception). > Now a contracted exceptions scenario: The programmer contracts a > middle-layer subprogram as non-propagating anything he does not want to. He > does not write any handlers, just compiles the code. The compiler complains > about E1. Aha - he says, where that E1 comes from? This repeats until all > low-level exceptions are caught, *understood* and handled. That would be ideal, and very much in the Ada spirit. But I can see why it is not an easy addition to Ada. >>The main problem I see in contracted exceptions is the problem with >>layered architectures where some intermediate layers are >>general/generic and not application-specific.... > > I think there is no simple answer to this. What could help IMO is: > > 1. Conditional exception contracts (for things like Storage_Error and > exceptions from the closures) > > 2. Inheritable exception contracts (to be able to refer to a group of > exceptions from another subprogram) > > 3. Making exceptions an ordered type with some kind of tree-like distance. > > 4. Renaming/delegation of exceptions. And perhaps also 5. Exceptions as formal generic parameters. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-11 13:21 ` Exceptions Niklas Holsti @ 2007-12-12 0:01 ` Randy Brukardt 2007-12-12 11:37 ` Exceptions Niklas Holsti 2007-12-12 14:37 ` Exceptions Robert A Duff 2007-12-12 11:00 ` Exceptions Dmitry A. Kazakov 1 sibling, 2 replies; 97+ messages in thread From: Randy Brukardt @ 2007-12-12 0:01 UTC (permalink / raw) "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message news:475e8bde$0$27850$4f793bc4@news.tdc.fi... ... > And perhaps also > > 5. Exceptions as formal generic parameters. Ada has this (although it isn't obvious): just pass an Ada.Exceptions.Exception_Id to the generic. That is, given a generic spec something like: generic My_Exception : Ada.Exceptions.Exception_Id := Constraint_Error'Identity; package Gen is ... you can instantiate it with any exception you like: package Inst is new Gen (Program_Error'Identity); and you can raise the exception inside the generic: Ada.Exceptions.Raise_Exception (My_Exception, Message => "Wow!"); and you can even handle the exception with a little cleverness: when Occ:others => if Ada.Exceptions.Exception_Identity (Occ) = My_Exception then -- Handle My_Exception. else raise; -- Not the one we want. end if; (This last is how Janus/Ada has to implement handlers for exceptions declared inside of generics anyway, so in our case at least, the code cost is essentially the same.) All but the last as just as good as a "real" exception formal, and the last doesn't happen that much in reusable stuff (usually such things are originating or propagating exceptions, not handling them). In any case, the fact that it is relatively easy to do this is why there is no formal exception parameter. Randy. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-12 0:01 ` Exceptions Randy Brukardt @ 2007-12-12 11:37 ` Niklas Holsti 2007-12-12 13:14 ` Exceptions Dmitry A. Kazakov 2007-12-12 14:37 ` Exceptions Robert A Duff 1 sibling, 1 reply; 97+ messages in thread From: Niklas Holsti @ 2007-12-12 11:37 UTC (permalink / raw) Randy Brukardt wrote: > "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message > news:475e8bde$0$27850$4f793bc4@news.tdc.fi... > ... > >>And perhaps also >> >> 5. Exceptions as formal generic parameters. > > > Ada has this (although it isn't obvious): just pass an > Ada.Exceptions.Exception_Id to the generic. That is, given a generic spec > something like: > > generic > My_Exception : Ada.Exceptions.Exception_Id := > Constraint_Error'Identity; > package Gen is ... Ha, a good technique to know, thanks. > In any case, the fact that it is relatively easy to do this is why there is > no formal exception parameter. If the implementation with Exception_Id is so easy, I wonder that the syntax with "exception" as formal parameter is not included in the language. But I know that language extensions are prioritized, and in fact I have never needed a formal exception parameter, although I have sometimes written wrappers for instances of generics just to translate an exception defined and raised by the generic into some other exception for the user of the generic. In any plan to extend Ada with exception contracts, I think that formal exception parameters should be included, or else the contract should allow exceptions to be named by Exception_Id as well as by the lexical identifier. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-12 11:37 ` Exceptions Niklas Holsti @ 2007-12-12 13:14 ` Dmitry A. Kazakov 0 siblings, 0 replies; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-12 13:14 UTC (permalink / raw) On Wed, 12 Dec 2007 13:37:09 +0200, Niklas Holsti wrote: > If the implementation with Exception_Id is so easy, I wonder that > the syntax with "exception" as formal parameter is not included in > the language. But I know that language extensions are prioritized, > and in fact I have never needed a formal exception parameter, > although I have sometimes written wrappers for instances of > generics just to translate an exception defined and raised by the > generic into some other exception for the user of the generic. > > In any plan to extend Ada with exception contracts, I think that > formal exception parameters should be included, or else the > contract should allow exceptions to be named by Exception_Id as > well as by the lexical identifier. The reverse, the keyword "exception" should be dropped and replaced by a plain type name Standard.Exception. Then we would be able to pass an exception (or an array of) wherever we wished to. (Exception_Id is IMO a hack) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-12 0:01 ` Exceptions Randy Brukardt 2007-12-12 11:37 ` Exceptions Niklas Holsti @ 2007-12-12 14:37 ` Robert A Duff 2007-12-13 19:20 ` Exceptions Randy Brukardt 1 sibling, 1 reply; 97+ messages in thread From: Robert A Duff @ 2007-12-12 14:37 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message > news:475e8bde$0$27850$4f793bc4@news.tdc.fi... > ... >> And perhaps also >> >> 5. Exceptions as formal generic parameters. > > Ada has this (although it isn't obvious): just pass an > Ada.Exceptions.Exception_Id to the generic. That is, given a generic spec > something like: > > generic > My_Exception : Ada.Exceptions.Exception_Id := > Constraint_Error'Identity; > package Gen is ... Yeah, you can do that. But IMHO this area of the language is a mess. Making exceptions be first-class objects would make the language simpler, easier to implement, and more powerful. - Bob ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-12 14:37 ` Exceptions Robert A Duff @ 2007-12-13 19:20 ` Randy Brukardt 2007-12-13 20:15 ` Exceptions Robert A Duff 0 siblings, 1 reply; 97+ messages in thread From: Randy Brukardt @ 2007-12-13 19:20 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wcctzmonfmn.fsf@shell01.TheWorld.com... > "Randy Brukardt" <randy@rrsoftware.com> writes: > > > "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message > > news:475e8bde$0$27850$4f793bc4@news.tdc.fi... > > ... > >> And perhaps also > >> > >> 5. Exceptions as formal generic parameters. > > > > Ada has this (although it isn't obvious): just pass an > > Ada.Exceptions.Exception_Id to the generic. That is, given a generic spec > > something like: > > > > generic > > My_Exception : Ada.Exceptions.Exception_Id := > > Constraint_Error'Identity; > > package Gen is ... > > Yeah, you can do that. > > But IMHO this area of the language is a mess. > > Making exceptions be first-class objects would make the language > simpler, easier to implement, and more powerful. Right, but in that case we *still* wouldn't need formal exceptions, because formal objects would serve just as well. Which really was my point - no sense in adding more cruft for that. Randy. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-13 19:20 ` Exceptions Randy Brukardt @ 2007-12-13 20:15 ` Robert A Duff 0 siblings, 0 replies; 97+ messages in thread From: Robert A Duff @ 2007-12-13 20:15 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > Right, but in that case we *still* wouldn't need formal exceptions, because > formal objects would serve just as well. Which really was my point - no > sense in adding more cruft for that. Exactly! The desire for generic formal exceptions is a symptom of the problem, to which first-class exceptions are the obvious clean solution. - Bob ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-11 13:21 ` Exceptions Niklas Holsti 2007-12-12 0:01 ` Exceptions Randy Brukardt @ 2007-12-12 11:00 ` Dmitry A. Kazakov 1 sibling, 0 replies; 97+ messages in thread From: Dmitry A. Kazakov @ 2007-12-12 11:00 UTC (permalink / raw) On Tue, 11 Dec 2007 15:21:57 +0200, Niklas Holsti wrote: > Exception contracts could become a considerable part of the source > code, especially if they would have to include the "always > possible" exceptions like Storage_Error and in the absence of any > SPARK-like analysis to exclude impossible exceptions from the contract. Unluckily, but for backward compatibility an missing contract should be treated as "raises exception'Class," i.e. anything. This is a problem with most of new things recently introduced in Ada, that the defaults are more verbose than their less safe counterparts. For example "abstract", "interface", "overriding". >> A typical scenario: A lazy (let's say busy) programmer designs some set of >> low-level primitives raising some exceptions. Then he starts to write a >> middle layer that reuses those primitives, not necessarily in exactly this >> order, but anyway. The exceptions of the middle layer are different, and of >> course, the lower level exceptions do not propagate out the middle layer. >> At this point he has already forgot most of when and what the lower level >> raises. He remembers the exceptions E3 and E10, but the rest is vanished. >> He decides whether to use "when others" but has no clear idea what to do >> there, so maybe he places something looking more or less appropriate there >> hoping that the debugging phase will shed more light on the issue, or just >> drop it, depending on how much coffee he already had. The rest is obvious. >> Does it sound familiar? > > Not really. I use informal exception contracts (in comments > describing each and every subprogram), I do it as well. > so I have not experienced > that kind of mess. But I have mistakenly omitted a necessary > handler once or twice, generally when the raise-to-handle distance > has been very large (fatal or semi-fatal exception). The problem is that you have to analyse the descriptions of all m subprograms you call in the given scope. Remember also the figure n of the scopes where an exception propagates without handling. That gives us m x n (width x depth) of the search as the number of things to keep in the weary head at once. It is tedious and error prone, especially when the code gets changed. >> Now a contracted exceptions scenario: The programmer contracts a >> middle-layer subprogram as non-propagating anything he does not want to. He >> does not write any handlers, just compiles the code. The compiler complains >> about E1. Aha - he says, where that E1 comes from? This repeats until all >> low-level exceptions are caught, *understood* and handled. > > That would be ideal, and very much in the Ada spirit. But I can see > why it is not an easy addition to Ada. It would be difficult to compiler vendors, because they will have to add exception contracts to all language constructs and library subprograms and then maintain them upon porting the compiler to another target. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-10 8:22 ` Exceptions Dmitry A. Kazakov 2007-12-10 9:20 ` Exceptions Georg Bauhaus 2007-12-10 12:09 ` Exceptions Niklas Holsti @ 2007-12-11 2:12 ` Randy Brukardt 2007-12-11 15:17 ` Exceptions Robert A Duff 2 siblings, 1 reply; 97+ messages in thread From: Randy Brukardt @ 2007-12-11 2:12 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:1kxk3hlfa25dw$.fl2wvbn0tpbg$.dlg@40tude.net... ... > 1. How often do you declare a new exception when writing a new subprogram? > My guess is about 1 / 10_000. For me, it is more like 1/100. Most subsystems get their own set of exceptions. > 2. How often does a caller "eat" an exception of the callee instead of > propagating it further? My guess is 1 / 10. This I agree with, and it is my primary objection to exception contracts. This means that you'll have to write long-winded handlers and/or contracts on 9/10 of the calls. That is, it is the common case that takes more work. That's usually bad. > There is not that many handlers in a good designed code. This is probably > the reason why people forget to handle exceptions properly. They are not > that visible. That's true: a lot of systems that I write have no handlers at all because any exception being raised is a bug, and I want to know. The biggest problem is insuring enough test coverage to make sure that the (latent) exceptions (that is, bugs) get raised. Most of the handlers I do write are of the form: begin Open (...); -- File or socket or ... exception when others => -- Couldn't open whatever. Abort program or process. end; -- Use the open file. But I'm not usually writing safety-critical systems. For programs that need to keep running (for example, a mail server), I use a single global others handler that logs any exceptions, since there should be none. But there would no way to prove that statically, and I don't think I'd want to have to write code structured to be able to try. Randy. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-11 2:12 ` Exceptions Randy Brukardt @ 2007-12-11 15:17 ` Robert A Duff 2007-12-12 0:10 ` Exceptions Randy Brukardt 0 siblings, 1 reply; 97+ messages in thread From: Robert A Duff @ 2007-12-11 15:17 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> 2. How often does a caller "eat" an exception of the callee instead of >> propagating it further? My guess is 1 / 10. > > This I agree with, and it is my primary objection to exception contracts. > This means that you'll have to write long-winded handlers and/or contracts > on 9/10 of the calls. ... This 1/10 number seems to be a guess at some sort of average (as in "mean"). I think it's misleading for the same reason it's misleading to say "The average income in so-and-so town is $1,000,000 per year". It might mean everybody's well off, or it might mean there's one super-rich guy, and everybody else in that town is starving. I think there are two kinds of exceptions: one that is handled approximately 1 level up the call chain, and the other that is handled way far up the call chain (near the main program, or not at all -- "not at all" = "by the Ada RTS"). The former kind is the one that might benefit from exception contracts. For the latter kind, one would use unchecked exceptions. Thus there is never a case where you are "forced" to mention the same exception all the way up 10 levels. Note that if you have a checked exception, and it really should be an unchecked one for some particular client, that client can turn it into an unchecked exception at that level, with no need to mention it in the next 9 levels. - Bob ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-11 15:17 ` Exceptions Robert A Duff @ 2007-12-12 0:10 ` Randy Brukardt 2007-12-13 19:58 ` Exceptions Robert A Duff 2007-12-14 0:53 ` Exceptions Ray Blaak 0 siblings, 2 replies; 97+ messages in thread From: Randy Brukardt @ 2007-12-12 0:10 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccr6ht5ki4.fsf@shell01.TheWorld.com... ... > This 1/10 number seems to be a guess at some sort of average (as in > "mean"). I think it's misleading for the same reason it's misleading to > say "The average income in so-and-so town is $1,000,000 per year". It > might mean everybody's well off, or it might mean there's one super-rich > guy, and everybody else in that town is starving. > > I think there are two kinds of exceptions: one that is handled > approximately 1 level up the call chain, and the other that is handled > way far up the call chain (near the main program, or not at all > -- "not at all" = "by the Ada RTS"). > > The former kind is the one that might benefit from exception contracts. > For the latter kind, one would use unchecked exceptions. Thus there > is never a case where you are "forced" to mention the same exception > all the way up 10 levels. > > Note that if you have a checked exception, and it really should be an > unchecked one for some particular client, that client can turn it into > an unchecked exception at that level, with no need to mention it > in the next 9 levels. I don't buy the supposed need for two kinds of exceptions. It seems to me to be an implicit recognition of the fact that the contracts aren't sufficiently useful for many kinds of subprograms. I think it would be better to fix the capability of the contracts (if that's possible) than to define a trivial way to avoid them. Once you have unchecked exceptions, the contract really doesn't tell you anything interesting (since it is the propagation of predefined exceptions that usually lead to bugs; only the rare case where the predefined exception is caught will tell you anything at all). Moreover, the temptation is overwhelming to use the unchecked kind everywhere, because it is less hassle and the checked kind doesn't buy that much anyway (it doesn't guarentee that all exceptions are handled, but only the rare few that are declared checked). It's much like the accessibility rules in Ada. They're immensely complicated, yet their original primary goal is completely ignored. I've never yet found an Ada program where I could use 'Access on an object; I don't even bother trying anymore. So why have all of that complication? (Yes, I know its useful for subprograms and tagged types, and we can't avoid it there.) Randy. I vie ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-12 0:10 ` Exceptions Randy Brukardt @ 2007-12-13 19:58 ` Robert A Duff 2007-12-14 0:53 ` Exceptions Ray Blaak 1 sibling, 0 replies; 97+ messages in thread From: Robert A Duff @ 2007-12-13 19:58 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > I don't buy the supposed need for two kinds of exceptions. Maybe "kind" is the wrong term. I think you want to be able to say, "X can be raised by anything in this scope (including child packages)". X might be Storage_Error, for example. In fact, that should be the default for Storage_Error -- there's no point in saying "This can raise S_E" on every procedure in the program! In any case, if you have checked exceptions, then you definitely need unchecked ones. That is, you need some way to say, "This cannot happen, and I know that, and in this case I [think I] am smarter than the compiler." >... It seems to me to > be an implicit recognition of the fact that the contracts aren't > sufficiently useful for many kinds of subprograms. I think it would be > better to fix the capability of the contracts (if that's possible) than to > define a trivial way to avoid them. > > Once you have unchecked exceptions, the contract really doesn't tell you > anything interesting (since it is the propagation of predefined exceptions > that usually lead to bugs; only the rare case where the predefined exception > is caught will tell you anything at all). Moreover, the temptation is > overwhelming to use the unchecked kind everywhere, because it is less hassle > and the checked kind doesn't buy that much anyway (it doesn't guarentee that > all exceptions are handled, but only the rare few that are declared > checked). OK, I think you've convinced me, at least in the context of Ada, and probably Java. I think Constraint_Error needs to be a checked exception -- otherwise, you miss a lot of bugs. But pretty-much anything can raise C_E in Ada. The solution must lie in having pre/post conditions and invariants, and a fairly powerful way of checking them statically. That's far from the existing Ada. Clearly, if: for I in A'Range loop ... A(I) ... and: while X /= null loop ... X.all ... require a handler for Constraint_Error, or a declaration that this procedure can propagate it, then the feature is not terribly useful. What I really want is something like SPARK, but with much less restriction on features that can be used. > It's much like the accessibility rules in Ada. They're immensely > complicated, yet their original primary goal is completely ignored. I've > never yet found an Ada program where I could use 'Access on an object; I > don't even bother trying anymore. So why have all of that complication? > (Yes, I know its useful for subprograms and tagged types, and we can't avoid > it there.) - Bob ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-12 0:10 ` Exceptions Randy Brukardt 2007-12-13 19:58 ` Exceptions Robert A Duff @ 2007-12-14 0:53 ` Ray Blaak 2007-12-14 2:48 ` Exceptions Randy Brukardt 1 sibling, 1 reply; 97+ messages in thread From: Ray Blaak @ 2007-12-14 0:53 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > Once you have unchecked exceptions, the contract really doesn't tell you > anything interesting (since it is the propagation of predefined exceptions > that usually lead to bugs; only the rare case where the predefined exception > is caught will tell you anything at all). Even with checked exceptions the contract still doesn't help, since unchecked exceptions are always possible in one form or another (e.g. allocation failures, program errors, truly unexpected failures). You can't just die. > Moreover, the temptation is overwhelming to use the unchecked kind > everywhere, because it is less hassle and the checked kind doesn't buy that > much anyway (it doesn't guarentee that all exceptions are handled, but only > the rare few that are declared checked). I see nothing wrong with following that temptation. Following that temptation saves time. Basically, the effort at trying to statically prove that all exceptions are handled is a waste of time. Even if the language supports checked exceptions, unchecked ones can still leak through. Having a sort of "unexpected exception" policy let's you catch any surprises reasonable, and you can always go back and tweak the code to handle any specific ones better should that prove necessary. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-14 0:53 ` Exceptions Ray Blaak @ 2007-12-14 2:48 ` Randy Brukardt 2007-12-14 6:33 ` Exceptions Ray Blaak 0 siblings, 1 reply; 97+ messages in thread From: Randy Brukardt @ 2007-12-14 2:48 UTC (permalink / raw) "Ray Blaak" <rAYblaaK@STRIPCAPStelus.net> wrote in message news:uzlwe5c7t.fsf@STRIPCAPStelus.net... > "Randy Brukardt" <randy@rrsoftware.com> writes: ... > > Moreover, the temptation is overwhelming to use the unchecked kind > > everywhere, because it is less hassle and the checked kind doesn't buy that > > much anyway (it doesn't guarentee that all exceptions are handled, but only > > the rare few that are declared checked). > > I see nothing wrong with following that temptation. Following that temptation > saves time. > > Basically, the effort at trying to statically prove that all exceptions are > handled is a waste of time. Even if the language supports checked exceptions, > unchecked ones can still leak through. That was my point; ther language *should not have* unchecked exceptions if it is going to bother with any checking. Then there is no possibility of "sneaking through" (modulo compiler or hardware bugs). Yes, you'd have to declare Storage_Error on (nearly) every routine (and I think that is a good thing in such an environment). Such a language would require substantial static analysis at compile-time (but that is practical these days), and would be a lot closer to the promise of "no bugs if it compiles" (Ada already gets quite a bit of the way there). Still I have to wonder if many people would want to use such a language (writing code is necessarily harder), and even if they did, if anyone could stand the language definition effort. Randy. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-14 2:48 ` Exceptions Randy Brukardt @ 2007-12-14 6:33 ` Ray Blaak 0 siblings, 0 replies; 97+ messages in thread From: Ray Blaak @ 2007-12-14 6:33 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > That was my point; ther language *should not have* unchecked exceptions if > it is going to bother with any checking. Then there is no possibility of > "sneaking through" (modulo compiler or hardware bugs). Yes, you'd have to > declare Storage_Error on (nearly) every routine (and I think that is a good > thing in such an environment). Such a language would require substantial > static analysis at compile-time (but that is practical these days), and > would be a lot closer to the promise of "no bugs if it compiles" (Ada > already gets quite a bit of the way there). > > Still I have to wonder if many people would want to use such a language > (writing code is necessarily harder), and even if they did, if anyone could > stand the language definition effort. Well that's just it. No one would use it since they wouldn't be able to get any work done. They would be spending too much time writing exception declarations and handlers. And for what? What does having Storage_Error declared everywhere buy you? You knew that going in. And how would you handle it? Crash or log it. You can do that in one place at the top level. The vast majority of those forced handlers would be tedious and repetitive, excactly the kind of thing that can be automated, and thus made invisible; in other words, to be turned into unchecked exceptions. Another way to view unchecked exceptions is that they are the language's way of having an implied exception "can raise" contracts declared everywhere. Programming languages are a tool for *people* to instruct computers what to do, not the other way round. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Exceptions 2007-12-06 15:00 Exceptions shaunpatterson ` (4 preceding siblings ...) 2007-12-07 16:55 ` Exceptions Adam Beneschan @ 2007-12-08 10:03 ` Stephen Leake 5 siblings, 0 replies; 97+ messages in thread From: Stephen Leake @ 2007-12-08 10:03 UTC (permalink / raw) shaunpatterson@gmail.com writes: > Is there any way to force programmers to catch exception that > your function throws? Something like Java forcing coders to > put try/catch blocks What do you mean by "force"? If your function throws an exception, in Ada or Java, the runtime semantics define what happens. If a caller of your function wants to handle the exception, they can. If they don't want to, they can do that as well. What is the use case you have in mind? -- -- Stephe ^ permalink raw reply [flat|nested] 97+ messages in thread
end of thread, other threads:[~2007-12-15 5:29 UTC | newest] Thread overview: 97+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-12-06 15:00 Exceptions shaunpatterson 2007-12-06 21:24 ` Exceptions tmoran 2007-12-07 8:54 ` Exceptions Dmitry A. Kazakov 2007-12-07 10:21 ` Exceptions Georg Bauhaus 2007-12-07 15:11 ` Exceptions shaunpatterson 2007-12-07 16:08 ` Exceptions Gautier 2007-12-07 18:56 ` Exceptions Simon Wright 2007-12-08 10:04 ` Exceptions Stephen Leake 2007-12-08 3:30 ` Exceptions Randy Brukardt 2007-12-08 10:09 ` Contracted exceptions for Ada (was: Exceptions) Dmitry A. Kazakov 2007-12-09 10:22 ` Contracted exceptions for Ada Stephen Leake 2007-12-09 11:02 ` Dmitry A. Kazakov 2007-12-11 8:10 ` Stephen Leake 2007-12-11 10:36 ` Dmitry A. Kazakov 2007-12-09 15:11 ` Contracted exceptions for Ada (was: Exceptions) Martin Krischik 2007-12-09 17:36 ` Contracted exceptions for Ada Dmitry A. Kazakov 2007-12-09 18:39 ` Simon Wright 2007-12-10 8:19 ` Dmitry A. Kazakov 2007-12-10 20:25 ` Simon Wright 2007-12-11 8:50 ` Dmitry A. Kazakov 2007-12-11 20:50 ` Simon Wright 2007-12-12 10:20 ` Dmitry A. Kazakov 2007-12-09 19:04 ` Martin Krischik 2007-12-10 8:20 ` Dmitry A. Kazakov 2007-12-09 22:09 ` Robert A Duff 2007-12-10 7:09 ` Stefan Lucks 2007-12-10 16:57 ` Robert A Duff 2007-12-11 1:53 ` Contracted exceptions for Ada (was: Exceptions) Randy Brukardt 2007-12-11 9:16 ` Contracted exceptions for Ada Dmitry A. Kazakov 2007-12-12 0:26 ` Randy Brukardt 2007-12-08 12:26 ` Exceptions Peter C. Chapin 2007-12-08 14:01 ` Exceptions Dmitry A. Kazakov 2007-12-08 18:01 ` Exceptions Peter C. Chapin 2007-12-09 10:06 ` Exceptions Dmitry A. Kazakov 2007-12-09 12:40 ` Exceptions Peter C. Chapin 2007-12-09 14:31 ` Exceptions Dmitry A. Kazakov 2007-12-09 16:38 ` Exceptions Peter C. Chapin 2007-12-10 8:31 ` Exceptions Dmitry A. Kazakov 2007-12-09 21:56 ` Exceptions Robert A Duff 2007-12-09 10:24 ` Exceptions Stephen Leake 2007-12-09 12:46 ` Exceptions Peter C. Chapin 2007-12-09 21:39 ` Exceptions Robert A Duff 2007-12-09 22:13 ` Exceptions Georg Bauhaus 2007-12-11 8:07 ` Exceptions Stephen Leake 2007-12-11 20:28 ` Exceptions Simon Wright 2007-12-12 22:10 ` Exceptions Maciej Sobczak 2007-12-13 13:40 ` Exceptions Robert A Duff 2007-12-13 14:00 ` Exceptions Maciej Sobczak 2007-12-13 14:44 ` Exceptions Robert A Duff 2007-12-14 0:46 ` Exceptions Ray Blaak 2007-12-14 2:36 ` Exceptions Randy Brukardt 2007-12-14 6:21 ` Exceptions Ray Blaak 2007-12-14 12:40 ` Exceptions Georg Bauhaus 2007-12-14 17:29 ` Exceptions Robert A Duff 2007-12-14 19:32 ` Exceptions Dmitry A. Kazakov 2007-12-15 5:29 ` Exceptions Ray Blaak 2007-12-13 19:29 ` Exceptions Randy Brukardt 2007-12-12 19:18 ` Exceptions Martin Krischik 2007-12-13 13:27 ` Exceptions Robert A Duff 2007-12-13 23:25 ` Exceptions Ray Blaak 2007-12-06 21:25 ` Exceptions Gautier 2007-12-07 4:29 ` Exceptions anon 2007-12-07 4:43 ` Exceptions, part 2 anon 2007-12-07 16:55 ` Exceptions Adam Beneschan 2007-12-07 18:59 ` Exceptions Simon Wright 2007-12-08 0:38 ` Exceptions Adam Beneschan 2007-12-09 21:45 ` Exceptions Robert A Duff 2007-12-09 22:40 ` Exceptions Georg Bauhaus 2007-12-10 8:22 ` Exceptions Dmitry A. Kazakov 2007-12-10 9:20 ` Exceptions Georg Bauhaus 2007-12-10 9:30 ` Exceptions Georg Bauhaus 2007-12-10 10:56 ` Exceptions Dmitry A. Kazakov 2007-12-11 2:18 ` Exceptions Randy Brukardt 2007-12-11 8:19 ` Exceptions Georg Bauhaus 2007-12-11 11:55 ` Exceptions Dmitry A. Kazakov 2007-12-11 16:13 ` Exceptions Georg Bauhaus 2007-12-12 11:18 ` Exceptions Dmitry A. Kazakov 2007-12-10 12:09 ` Exceptions Niklas Holsti 2007-12-10 13:08 ` Exceptions Dmitry A. Kazakov 2007-12-10 20:02 ` Exceptions Niklas Holsti 2007-12-11 12:31 ` Exceptions Dmitry A. Kazakov 2007-12-11 13:21 ` Exceptions Niklas Holsti 2007-12-12 0:01 ` Exceptions Randy Brukardt 2007-12-12 11:37 ` Exceptions Niklas Holsti 2007-12-12 13:14 ` Exceptions Dmitry A. Kazakov 2007-12-12 14:37 ` Exceptions Robert A Duff 2007-12-13 19:20 ` Exceptions Randy Brukardt 2007-12-13 20:15 ` Exceptions Robert A Duff 2007-12-12 11:00 ` Exceptions Dmitry A. Kazakov 2007-12-11 2:12 ` Exceptions Randy Brukardt 2007-12-11 15:17 ` Exceptions Robert A Duff 2007-12-12 0:10 ` Exceptions Randy Brukardt 2007-12-13 19:58 ` Exceptions Robert A Duff 2007-12-14 0:53 ` Exceptions Ray Blaak 2007-12-14 2:48 ` Exceptions Randy Brukardt 2007-12-14 6:33 ` Exceptions Ray Blaak 2007-12-08 10:03 ` Exceptions Stephen Leake
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox