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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!samsung!sdd.hp.com!think!linus!eachus From: eachus@linus.mitre.org (Robert I. Eachus) Newsgroups: comp.lang.ada Subject: Re: "silly" (?) Ada semantics Message-ID: Date: 6 Jun 90 22:27:03 GMT References: <1919@sparko.gwu.edu> <644579683.25696@minster.york.ac.uk> <1936@sparko.gwu.edu> Sender: usenet@linus.mitre.org Organization: The Mitre Corporation, Bedford, MA In-reply-to: mfeldman@seas.gwu.edu's message of 6 Jun 90 16:09:42 GMT List-Id: In article <1936@sparko.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes: > You make a very good point! I think the group would benefit from hearing from > an authoritative voice on this issue. A vendor? An ARG member? Does the > current interpretation of the LRM indeed _require_ that a compilation > be completed in case of a guaranteed exception that the compiler detects? > If so, I'm sure there must be a good motivation for it, but it escapes me. > Would some important principle be violated if the compiler were to treat > a sure-to-be-raised exception as a fatal error (at least optionally?) I sort of already answered this, but I guess as an ARG member I should take a swing at such a slow curve ball. :-) There are many useful programs which will always raise an exception. Would you be appalled if your compiler declined to compile the following procedure because it always rasied an error? After all the companion procedure Recoverable_File_Error compiled without problem... with Text_IO; procedure Unrecoverable_File_Error(Error_Number: in Integer; File: in Text_IO.File_Type; Message: in String) is begin if Text_IO.Is_Open(File) then Put_Line("Unrecoverable Error" & Integer'IMAGE(Error_Number) & " in file " & Text_IO.NAME(File) & ": " & Message); Text_IO.Close(File); else Put_Line("Unrecoverable Error" & Integer'IMAGE(Error_Number) & ": " & Message); end if; raise TEXT_IO.DEVICE_ERROR; end Unrecoverable_File_Error; (I am only raising DEVICE_ERROR and putting the message on CURRENT_OUT to simplify the example. I also left out the exception handler around the close.) This is a simple example, but there are many embedded systems where the only way to get out of the main program (or some subprogram) is when an exceptional situation arises. Also, a file reading procedure which counts on END_OF_FILE to get out of the read loop is considered in poor taste, but what about a program expecting to get its input from a file-like device that will only signal EOF when it fails? Now for those of you who live in the debugger...How loud would you scream if the compiler told you: "After extensive analysis, it has been determined that this procedure will always raise some exception. Compilation Aborted." Note that the compiler is specifically allowed to check for erroneous code and replace it with code which raises PROGRAM_ERROR (1.6(10)). This is allowed because it was felt that in some markets, PROGRAM_ERROR during test was preferable to programs which produced different results on different runs with the same data. (But only in cases not involving the non-determinism of tasking.) -- Robert I. Eachus Amiga 3000 - The hardware makes it great, the software makes it awesome, and the price will make it ubiquitous.