Novice Questions on Ada Exceptions

Novice Questions on Ada Exceptions

[Tom McClory]

I am attempting to port the Ada Test an Analysis Tools package, 
(contributed by Intermetrics to the Ada Repository) to the UNIX 
operating system using the Verdix Ada Compiler (release 5.4).  
The package compiled with no obvious errors, and what appear 
to be minor warnings.  However, the program fails during 
operation with the following exception message:

** MAIN PROGRAM ABANDONED -- EXCEPTION "program_error" RAISED

The VADS debugger sheds a little more light on this with the
output:

RM 11.3(3): RAISE statement reraised exception

This leads to several questions . . .

1) Does anyone have experience porting/using this "Ada Test
and Analysis Tools" package from the Ada Repository?  Are there 
any configuration issues I may have missed?  The changes I made 
were to define a type "long float" and to fix a few typographical 
errors (missing spaces) that may have been introduced during upload.

2) A more general question . . . what are typical causes for 
"PROGRAM_ERROR" exceptions?  More specifically, what might be causing
this error?  The text book I'm using (_Understanding Ada_, by 
Bray & Pokrass, 1985) mentions only "leaving a function without 
executing a return statement."  (Won't the compiler catch these?)

3) Even more general . . . what are good strategies for tracking the
source of exceptions in large programs you personally didn't write?
The behavior of the VADS debugger during exception handling seems 
shaky (I get warning messages about loosing track of pointers), 
so I don't trust the information I've gotten.  Neither the error 
message, nor the debugger, accurately pinpoint the source of the 
exception.  Rather, the debugger states "exception raised xxx 
instructions beyond the statement shown", which is the last 
statement in the last block of whatever file happened to be displayed 
when the exception triggered.  

Any suggestions are welcomed.  Thanks in advance.

Re: Novice Questions on Ada Exceptions

[stt]

One frequent cause of PROGRAM_ERROR is an elaboration-order
problem.  Whenever a subprogram is called before it has
been elaborated, PROGRAM_ERROR is raised.  This happens
most frequently when elaboration-time code
in one package calls subprograms in another package,
and the other package's body has not yet been elaborated.
This is something which sometimes shows up in
rehosting since elaboration-order determination is 
implementation-dependent.  

The usual fix is to
determine which package calls which other package at
elaboration time, and place a pragma Elaborate (see LRM 10.5:3)
in the calling package referencing the called package.
Note that if the called package calls other packages, there
may be a need to include additional pragma Elaborates on
those lower level packages.  Pragma Elaborate only forces
elaboration for a single level of dependency.  Hopefully,
Ada 9X will fix it so that it forces elaboration for
the closure of dependencies...

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138

Pragma ELABORATE (was: Re: Novice Questions on Ada Exceptions)

[adh]

In article <20600004@inmet> stt@inmet writes:
>The usual fix is to
>determine which package calls which other package at
>elaboration time, and place a pragma Elaborate (see LRM 10.5:3)
>in the calling package referencing the called package.
>Note that if the called package calls other packages, there
>may be a need to include additional pragma Elaborates on
>those lower level packages.  Pragma Elaborate only forces
>elaboration for a single level of dependency.  Hopefully,
>Ada 9X will fix it so that it forces elaboration for
>the closure of dependencies...

I assume that the possible need for additional pragma ELABORATEs is because
there may be further cases of package body being called before it has
elaborated that will be exposed when the first error is fixed.
The problem I have is with the suggestion that pragma ELABORATE should be
changed to force elaboration of all package (actually library unit?)
bodies in the closure of dependencies, as part of 9X.
I don't think this is necessary - the pragma is intended only to indicate
that prior elaboration of a particular body, whose specification will
already have been elaborated, is required.
Indeed, I can contrive examples where the current pragma ELABORATE
will ensure elaboration completes, but the proposed new semantics would
prevent elaboration (i.e. the package whose body carries the pragma ELABORATE
is in the closure of the bodies of units depended upon by the package
named by the pragma ELABORATE). Or am I missing somthing?

Andy Hutcheon (adh@uk.ac.york.minster)