"Gautier write-only address" <
gautier...@hotmail.com> wrote in message
news:1353f387-bb5a-4dc5...@googlegroups.com...
>> Any thoughts on pro's/con's of having the Ada standard packages
>> runtime provide extra information in the message string of exceptions ?
>
> It depends on the compiler. And of course it is advantage to provide more
> details.
> For instance HAC issues for...
>
> procedure CE_2 is
> i : Positive;
> j : Integer := 1;
> begin
> i := -j;
> end CE_2;
>
> the message:
> hac ce_2.adb
> HAC VM: raised Constraint_Error
> Out of range: pos, -1, is below (sub)type's lower bound, 1
> Trace-back: approximate location
> ce_2.adb: CE_2 at line 5
Janus/Ada has *always* done this (going all the way back to the original
Z-80 CP/M compiler). This particular case is not very expensive, since one
can use the fact that the out-of-range value is certainly in a register to
be tested in order to construct the message. And no real program cares about
the performance of raising Constraint_Error -- the main issue is one of
space (making the program larger).
For example, from a recent bug report:
** Unhandled CONSTRAINT_ERROR
Index or Subtype out of bounds - Pos of Error Value = 197807
On Line Number 37 In XCB_MAIN.DETERMINE_FILE_SIZE
Called from line number 40 In XCB_MAIN
It's possible to turn this off, but there hasn't been much need to do so
this century.
Randy.
P.S. I'd quibble with the OP, in that the vast majority of Constraint_Errors
have nothing to do with the standard library; their checks are compiled
directly into the code of your application; the only use of a library is to
raise an exception. We use special library calls for specific checks (like
the discrete range error discussed here); no strings are created in the user
code. An implementation would certainly have to do that as the alternative
would be to duplicate lots of complex code for each failed check -- but in
the absence of such information, the implementation probably uses the same
library call to raise all exceptions. Ergo, such a change probably isn't
easy for any implementation that doesn't do something like it already.