Re: contracted exceptions

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wccwsyfa5vf.fsf@shell01.TheWorld.com...

>> 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.

With my "implementer of Ada 2005" hat on, I'd say that's probably a good
thing.  ;-)

> 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.

I've been thinking about the issue purely in the abstract
(from-scratch language design).  If you add the "compatibility"
requirement, that probably makes it much harder, or even impossible.
And of course in the context of Ada revisions, compatibility IS a
requirement.

> 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!*),

Right, the "why" leads to preconditions and whatnot, as you note below.

>... 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...).

That's true with or without contracts.  Whenever an exception gets
turned into a different one, for whatever reason, you want debugging
facilities (interactive debugger, logging, etc) to be able to get
their hands on the original.

> Anyway, it would seem that real Preconditions and Invariants would be more
> useful...

Yes.  I'd say preconditions (etc) subsume the Java "what can this raise"
idea.  So my "few tweaks" comment above is rather an understatement.

>... (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.)

I did participate in those design discussions.  AdaCore has even
considered implementing that stuff as impl-def pragmas, but I don't
think it will happen any time soon.

- Bob