Re: Ada exception block does NOT work?

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

"Hyman Rosen" <hyman.rosen@gmail.com> writes:

> Jeffrey Carter wrote:
> > The try/catch block is one such symptom.
> 
> No. It would have been perfectly possible to not have
> 'try' at all, and simply allow a sequence of catch
> clauses to follow any statement. Bjarne Stroustrup
> addresses this explicitly in _The Design and Evolution
> of C++_. The problem was that the resulting code looked
> ambiguous and difficult to understand. Having explicit
> try and a brace-enclosed section enhanced readability.

I agree with Hyman Rosen here (and with Bjarne Stroustrup!).

Not only is it more readable to have a separate statement for handled
regions, it simplifies the language.  And it obviates the need for
extraneous block_statements.

On the other hand, it's not that big of a deal, either way.

> > That the C++ core language tends to have undefined/
> > implementation-defined semantics where Ada has semantics
> > defined in terms of exceptions is another.
> 
> The designers of C++ simply followed the lead of their
> parent language in not checking certain core operations.
> The choice was made not to check, so debating which
> mechanism would not be used to not report the error is
> silly. Where C++ does require checks, generally exceptions
> are raised on failure. (Formatted I/O allows the choice to
> silently fail subsequent operations once one fails, and
> then to check once for failure at the end.)

OK, fair enough.  But I still think allowing the programmer to choose
whether to do overflow checking or not is a far superior language design
than one that doesn't allow that choice.  The programmer, not the
language designer, is the only one in a position to make that choice.

> > On a more concrete level, Ada's was initially intended for critical,
> > real-time, embedded SW. Allowing an arbitrary object to be used
> > as/associated with an exception in such systems may not be a good idea.
> 
> But as we know from SPARK, use of Ada in such environments
> generally involves throwing away much of the existing language.
> Therefore I do not find this to be a valid argument.

I don't find it to be valid, either.  But I think your point about SPARK
is invalid, too, because many real-time embedded systems use much larger
subsets of Ada than SPARK.

The real issue is whether exception (occurrences) can have non-static
size.  If that's bad for your real-time system, then don't use that
feature; it's not a good reason to leave the feature out of the
language.  Another case where the programmer, not the language design,
should make the decision.

> > Additionally, Ada allows nested scopes, which C and its descendants do
> > not. This allows the existence of anonymous exceptions, exceptions that
> > have propagated out of the scope of their definitions. Allowing
> > arbitrary objects as/associated with exceptions gives rise to a similar
> > set of problems as allowing type extensions at a deeper scope than the
> > parent.
> 
> Yes, that's a much better argument. It puts the cause squarely on
> other aspects of Ada's design rather than harrumphing and handwaving.
> By the way, it's not correct to say that Ada allows nested scopes and
> C-like languages do not. The problem here is that in Ada types are
> dynamic while in C-like languages all types are static regardless of
> the scope in which they are defined. So in those languages, there is
> no concept of an object being able to outlive its type, and thus no
> problem with throwing it out of the scope in which the type was
> defined.

But in both C++ and Ada, types have type descriptors (or method dispatch
tables, or whatever you want to call them).  These point at procedures.
And if those procedures can be nested, those procedures can depend on
(and modify) the stack-allocated data.

In other words, I agree with Jeff here, that the issue is nesting (not
staticness of types).

- Bob