From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,699cc914522aa7c4 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Structured exception information Date: Sun, 21 Jan 2007 18:45:44 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1169423146 860 192.74.137.71 (21 Jan 2007 23:45:46 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sun, 21 Jan 2007 23:45:46 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:/38rG5knvMejK+jdkCyTyPS8FKg= Xref: g2news2.google.com comp.lang.ada:8387 Date: 2007-01-21T18:45:44-05:00 List-Id: Stephen Leake writes: > Robert A Duff 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