Re: Program identification

[jvl@ocsystems.com (Joel VanLaven)]

tmoran@bix.com wrote:
: >>  produces:
: >>
: >>egad:TEST.BANG
: >>   On Line Number 8 In TEST.BADGUY
: >>Called from line number 12 In TEST
: >>, whew
: >
: >On which version of which compiler?  (I want that compiler! ;-))
:   RR Software's 3.07 Ada 95.  I forget whether I ran that test on their
: DOS/DPMI or Windows 95/NT, but would assume they do the same thing.

  Although I seem to have missed a number of intermediate messages, is
most definately a place where the compiler implementation makes all of the
difference.  Our PowerAda compiler gives similar "traceback" information,
as most good compilers should.  While it is not a rule in Ada, check out 
the Ada95 reference manual <11.4.1:19>, and that general area.  It states
that the exception message and information should be "useful for debugging."
Most people take that to include a "traceback" or "stack dump," but not 
nescesarily!  IMHO PowerAda has nice traceback messages, but you can judge
for yourself :)  Here is a sample program (sorry, I missed the example 
given earlier, or I would have just used that one :)  :
package b_pack is
  procedure gonna_break;
end b_pack;

package body b_pack is
  procedure gonna_break is
  a:float:=0.0;
  begin
    a:=a/a;
  end gonna_break;
end b_pack;

with b_pack; use b_pack;
procedure break_it is
begin
   gonna_break;
end break_it;


and traceback:

  Unhandled exception: CONSTRAINT_ERROR
  Message: Division by 0 (LRM 4.5.5:12)

  Traceback:
Raised in b_pack:gonna_break at line: 9
Raised in break_it:break_it at line: 16
Raised in <Main Environment Task> at line: 0

  One interesting question is what to call a procedure/subprogram when
generics are involved.  For instance, if make two instantiations of
float_io, fio and myfloat_io, is the name of the put procedure for
exceptions fio.put and myfloat_io.put, float_io.put, or something even
more complicated like <fio>.put (float_io) ?  These are decisions that
the language did not decide on, they were left to the implementors, for
better or for worse.
-- 
-- Joel VanLaven