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: mfb@mbunix.mitre.org (Michael F Brenner) Subject: Re: GNAT exception traceback Date: 1997/06/19 Message-ID: <5ob92l$lge@top.mitre.org>#1/1 X-Deja-AN: 251094932 References: <199706131810.OAA07239@seahunt.ctron.com> <01bc7a82$c57186a0$2a208b82@wd> Organization: The MITRE Corporation, Bedford Mass. Newsgroups: comp.lang.ada Date: 1997-06-19T00:00:00+00:00 List-Id: 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.