comp.lang.ada
 help / color / mirror / Atom feed
From: eachus@linus.mitre.org (Robert I. Eachus)
Subject: Re: "silly" (?) Ada semantics
Date: 6 Jun 90 22:27:03 GMT	[thread overview]
Message-ID: <EACHUS.90Jun6182703@aries.linus.mitre.org> (raw)
In-Reply-To: mfeldman@seas.gwu.edu's message of 6 Jun 90 16:09:42 GMT

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.

  reply	other threads:[~1990-06-06 22:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1990-06-02 21:08 "silly" (?) Ada semantics Michael Feldman
1990-06-05  9:54 ` ken
1990-06-06 16:09   ` Michael Feldman
1990-06-06 22:27     ` Robert I. Eachus [this message]
1990-06-07 14:32       ` Michael Feldman
1990-06-06 18:12   ` Robert I. Eachus
1990-06-07 17:27 ` stt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox