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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d4b13594b8779b99 X-Google-Attributes: gid103376,public From: #1/1 X-Deja-AN: 288310923 Sender: wemagor@sym1.cca.rockwell.com (Wayne Magor) References: <63ll1g$7f8$2@trumpet.uni-mannheim.de> Reply-To: No@Junk.Mail Distribution: world Organization: Rockwell Collins - Avionics Newsgroups: comp.lang.ada Date: 1997-11-08T00:00:00+00:00 List-Id: My biggest gripe with Ada exceptions is that there is no indication in the spec as to what exceptions a subprogram can raise (or propagate). You cannot know for sure that *your* code is correct until you examine the bodies of all the subprograms you call for "raise" statements. You then must examine all the subprograms that they call, and so forth. Perhaps a tool is needed that does this type of analysis. Then, at least comments can be added to every subprogram spec indicating what exceptions it could raise. Knowing this, you should be able to create a tool that tells you if any of your code is propagating exceptions that you didn't expect to be propagating. Then, if you don't want it to be propagated you can handle it in your subprogram. Recovering from unexpected exceptions is important in critical applications, but it's difficult to achieve.