Re: GNAT exception traceback

[mfb@mbunix.mitre.org (Michael F Brenner)]

R. Dewar:
>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.

R. Duff:
>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.

Depending on this silent behavior? The only argument against having
the ability to generate a traceback given in this thread was 
that it would take a lot of memory. Other, unspoken arguments 
similarly have nothing to do with people depending on not being
able to get the tracebacks at their option: (a) embedded systems
without neither monitor nor file system nor Net connection might
give a problem to compiler vendors who are not creative enough
to program this option in a manner compatible to the available
radio controlled hardware on the space ship; (b) tasks which
are aborted or which terminate abnormally might have been
starved off by a main program (think of obsolete species
whose societies evolve to take up to much of the resources
of the planet so they get calamatied away right in the middle
of their supposed evolution), and that main program does not care
about any appeals from them, however, programmers who arent part of
that great green ooze of evolution, might wish to know why and how 
they got starved off for anthropological reasons;
(c) the great beauty of the intertwining of the two major cables
(mega-threads) which make up comp.lang.ada, namely 
comp.style.ada and comp.fast.ada, which contrast the efficiency
versus the stylistic aesthetics, are twisted in such a way
that efficiency always wins, either by permitting the language
to do things the efficient way, or by being a source of
whining on the part of the efficienados (to coin a word :).

As long as it remained an option, and did not disturb the
many users of commercial products who do not wish to know
why their mouse hung up, there is nothing in the manual that
forbids a compiler/runtime option to generate tracebacks
for either the main program or tasks. 

In addition, there is nothing that prevents more accurate
tracebacks, better control over which exceptions are
treated as fatal errors for debugging purposes versus
which are just handled.