Re: contracted exceptions

"Robert A Duff" <bobduff@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:wccwsyfa5vf.fsf@xxxxxxxxxxxxxxxxxxxxxxx
Ray Blaak <rAYblaaK@xxxxxxxxxxxxxxxxxx> writes:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> writes:
I would like to see contracted exceptions...

The Java experience shows that compiler checked exception
specifications don't work.

I don't quite agree. I'd say the Java experience shows that the exact
rules of Java don't work very well. But that does not imply that the
whole idea can't work well.

I think Java is on the right track here, and with a few tweaks to the
rules would work quite well.

I'm not as convinced. We discussed this subject in the ARG and no one had
any ideas that were real improvements on the Java situation. (It's too bad
that you can't come to meetings more often, because you often have a unique
perspective on things.) Thus the idea was dropped.

It's fairly clear that the default for Ada would have to be to let
exceptions propagate (for compatibility with existing code, if for no other
reason). That might actually be the rule change that fixes the Java
problems, but it also would make any contracts not particularly relevant.

It is certainly true that in some cases (such as a public library like Claw)
you really do want to document all of the exceptions propagated (*and
why!*), and some compiler enforcement might be nice. But even there, it
would seem that such contracts would get in the way of debugging (if a
violated exception contract caused Program_Error to be raised, the original,
unexpected exception and its information would be lost, and that would make
debugging harder. I'd rather know about a Constraint_Error due to a null
access value being dereferenced than an exception contract being
violated...).

Anyway, it would seem that real Preconditions and Invariants would be more
useful (the rest of the original thread this was split from seems mainly to
be about a rather weak from of preconditions). We (the ARG) worked a lot
harder on those, but could never get the inheritance rules quite right. (And
thus it is dropped from the Amendment for a lack of maturity.)

Randy.


.

Relevant Pages

  • Re: CMutex /CEvent (multiple threads)
    ... deals with exception detection. ...  If your function does not handle an exception in Java, ... designer did not understand what a Mutex was and that the notion that Lock could return ... ...roll back transaction ...
    (microsoft.public.vc.mfc)
  • =?iso-8859-1?q?Re:_Beyond_Java_Tiger_-_Defekte_und_L=FCcken_in_Java?=
    ... > synchronized-Block erweitert und dann eine Bibliothek für Threads zur ... man kann nicht sicher mehrere locks requiren ... > Java machen kann, wenn man denn will. ... > eine Exception soll abgefangen werden damit ich noch ein CleanUp machen ...
    (de.comp.lang.java)
  • Re: datetime exception 0xC0000008 JRE 1.4 windows
    ... > sais 2am. ... because both keys had 3am. ... > This exception goes up through the JAVA and kills the program - but only ...
    (comp.lang.java.programmer)
  • datetime exception 0xC0000008 JRE 1.4 windows
    ... In Australia, daylight savings is supposed to end at 2am on the last sunday ... sais 2am. ... This exception goes up through the JAVA and kills the program - but only ...
    (comp.lang.java.programmer)
  • Re: contracted exceptions
    ... The Java experience shows that compiler checked exception ...
    (comp.lang.ada)