Re: Structured exception information

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>> It's certainly more difficult to implement data attached to
>> exceptions, compared to the Ada 83 feature, where an exception can be
>> represented as a fixed-size (one word) compile- or link-time-known
>> quantity.  Managing variable sized things is definitely harder.
>> But I fail to see how exceptions with Strings attached (he he)
>> is easier to implement than exceptions with arbitrary (typed) data
>> attached.
>
> This is related to an issue that you raised earlier;

Sorry, which issue did I raise, and when? -- I guess I've forgotten...

>... in Ada 2005 there
> is a limit of 200 characters on the string. I believe that is because
> exceptions with Strings must work even when the exception is
> Storage_Error due to either heap exhaustion or stack overflow.

I don't think that's the issue.  If you raise an exception with a String
attached (whether that's S_E or not), and there's no stack space to
allocate that String, then the run-time system needs to be prepared to
raise a "plain old" Storage_Error.  That's just a special case: if ANY
operation runs out of stack, the run-time system needs to be able to
raise S_E.  That's no big deal -- just reserve enough extra space on
every task's stack, so that raising S_E is always possible.  And that
"extra stack space" is a fixed small number of bytes.

I think the 200-char limit was based on concerns about managing the
memory.  (Misguided concerns, IMHO.)  The exception occurrence is
allocated on the stack at the point of the raise, and it somehow needs
to appear at the point of the handler.  That's tricky, but doable (after
all, Ada allows "return String", which is pretty much the same idea).
Heap allocation may be necessary in some cases (as Stroustrup points out
in one of his books on C++).  That's OK -- embedded systems might want
to avoid those cases.

> It's much better to trucate a String to 200 bytes than some
> user-defined type.

Indeed.  If a limit is needed (I don't think so), then truncation is
tolerable for Strings, but not for misc data types.

- Bob