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!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 23 Jan 2007 17:58:32 -0600
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
References: <eog0g5$2bn$1@cernne03.cern.ch> <u7ivnp09z.fsf@stephe-leake.org>
  <eoinoh$855$1@cernne03.cern.ch> <ud55drgzz.fsf@stephe-leake.org>
  <eolaen$b4h$1@cernne03.cern.ch> <ur6trwdov.fsf@stephe-leake.org>
  <eoqhhm$fjp$1@cernne03.cern.ch> <uac0dyap7.fsf@stephe-leake.org>
  <wccfya5u07k.fsf@shell01.TheWorld.com> <umz4c9f2z.fsf@stephe-leake.org>
  <wccr6tot047.fsf@shell01.TheWorld.com> <ubqkqdwnv.fsf@stephe-leake.org>
Subject: Re: Structured exception information
Date: Tue, 23 Jan 2007 17:59:54 -0600
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Message-ID: <y8-dnWsfVti0PCvYnZ2dnUVZ_sOknZ2d@megapath.net>
NNTP-Posting-Host: 64.32.209.38
X-Trace: 
 sv3-1nxLVxqi1YHAvwFQu2T8SbA51FaCX7ECZ0vF638oJ4CXlJdADuAPnv6WH5nd+2SKzmP1T3vIXFPVqSE!RXUtQ02p+btOfC25GxTPv2X78Kw3G4rYnOPCW4slM8J4MT0EZpRPyKuP1YHlqJt6BGA4+SKxrfk1!RCaJ764t+tN1/Q==
X-Complaints-To: abuse@megapath.net
X-DMCA-Complaints-To: abuse@megapath.net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint
 properly
X-Postfilter: 1.3.32
Xref: g2news2.google.com comp.lang.ada:8452
Date: 2007-01-23T17:59:54-06:00
List-Id: <comp.lang.ada>

Someone wrote: (I've lost track of the original author)

> >>... 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.

Sorry, that's FUD. That limit only applies in very limited circumstances
(Save_Exception, Reraise_Occurrence, reraise statement). The only one of
those that you even have a realistic chance of running into is reraise
statement, and if you really are worried about that limit, you can avoid the
limit be avoiding any of those constructs. So it shouldn't prevent the use
of (admittedly suboptimal) coding/decoding mechanisms.

An implementation that truncates messages for regular raise statements is
just plain wrong (go read 11.4.1(18) again if you don't believe me).

Because that's the case, it's hardly possible for it to be valuable to an
implementation to actually do that truncation. (You've got to already have a
mechanism for handling the unknown sized objects in an occurrence.) Users
need to push vendors into not using 11.4.1(18) [it's surely not a
requirement!]

                              Randy.