From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,91c5b958fecf5eff
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: GNAT exception traceback
Date: 1997/06/17
Message-ID: <EBxu4z.GFI@world.std.com>#1/1
X-Deja-AN: 250995484
References: <199706131810.OAA07239@seahunt.ctron.com> <dewar.866242346@merv>
 <01bc7a82$c57186a0$2a208b82@wd> <dewar.866540788@merv>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 1997-06-17T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <dewar.866540788@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>First: The slient disappearence of exceptions raised in tasks is *required*
>by the Ada language. The semantics of an unhandled exception is that it
>silently terminates the task in which it appears if this is not the
>environment task. This is not considered an error by the language definition.

Quite true -- the semantics of Ada is that it's not an error to have an
unhandled exception in a task.  Nonetheless, I think the default
behavior of all Ada implementations should be to print out an error
message (including a stack trace-back) when this happens.  You could
even get away with making this the *only* behavior -- nothing in the Ada
RM says the implementation can't print out interesting information
whenever it likes.  I'd be reluctant to go that far, however, because
somebody, somewhere is probably depending on this "silent" behavior.

Given an implementation that doesn't do the nice thing above, one should
put something like "when X: others => Report_Error(X);" at the bottom of
every task.

>(Note: I personally think this is an annoying little mistake in the definition
>of the language, what would be so terrible in requiring programmers to write
>
>   when others => null;
>
>at the top level of a task, if you really want this [typically undesirable]
>behavior?)

Strongly agree.

>That being said, in practice, for programs which do not use Constraint_Error
>as a control structure in the program (one would hope that would be nearly
>all programs, but sadly this is not the case), considering Constraint_Error
>to be always fatal is a very reasonable idea.

In *my* programs, Assertion_Failure is more common than
Constraint_Error, when a bug happens.

- Bob