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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1901f265c928a511 X-Google-Attributes: gid103376,public Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: new revision ada (exception handling) Date: Tue, 22 Jun 2004 17:09:23 +0100 Message-ID: <2jr3tjF149hg2U1@uni-berlin.de> References: <40BDBBFA.2020203@noplace.com> <1087475285.166449@master.nyc.kbcfp.com> <2jlepqF12qbb6U1@uni-berlin.de> <1774424.VSnnNmZCKX@linux1.krischik.com> X-Trace: news.uni-berlin.de 5Sd1Wd9EqxTJmlZdkaftYwIEeJkWykqU6BtZwiWpIley30juU= X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Xref: g2news1.google.com comp.lang.ada:1787 Date: 2004-06-22T17:09:23+01:00 List-Id: "Martin Krischik" wrote in message news:1774424.VSnnNmZCKX@linux1.krischik.com... > > Your solution detaches the information from the notification. > > This detachment causes problems, which are compounded by > > concurrency. If two exceptions are raised in a program and > > their state information is stored in some buffer such as > > a protected object, how will a handler determine which state > > belongs to which exception occurrence? > > Store them in an booch component map indexed by thread id. > I do that in AdaCL.Trace. I am intrigued by this technique. It is of importance to me, since I am currently thinking about how to implement exception handling according to the current CORBA Ada binding. There seem to be two problems with the solution you suggest: (1) Nested exception occurrances. If an exception is raised and handled within an exception handler, the parameters of the outer occurrance will be overwritten by those of the inner one. A solution would be for every handler (that uses parameters) to copy off the parameters before doing anything else (that could raise and handle an exception). However, this solution causes extra work, and is not neat; it seems bug-prone to me. (2) Memory management. The memory used up by the parameters of an exception will not be reclaimed at an appropriate time (for example, when there is no longer any possibility of the associated exception being handled). This is only a memory leakage problem, and may be considered of low significance, but I don't like it. In addition, the use of a map structure seems a bit heavyweight. I'd appreciate your comments. > Again: why XML when Ada has a perfectly usable system to > stream out data. i.E. 'Input and 'Output. Annex E is already > based on it so it could be used for extended exceptions as > well. I think a possible answer to this question is that XML is human-readable (or at least it is pure text), whereas Ada streams are (essentially) binary. I think the point of providing (only) string data for parametising exceptions in Ada 95 was to ensure that those parameters could simply be printed/displayed (by diagnostic software). XML encoded parameters could also be simply printed out, as well as being interpreted and used by knowledgeable software. However, I would not personally advocate this approach. The use of XML seems extremely heavyweight to me. I think a better idea would be to allow parameters to be added to an exception occurrance in the machine's internal format (possibly as a value of a type derived from an abstract root tagged type), in addition to an appropriate human-readable message being added to the occurrance's message. This way, diagnostic software can simply print the message, and knowledgable software can interpret the parameters directly. There would be no need for any endcoding or decoding software. Surely having to add an XML generator and parser to a piece of (embedded) software just to support exception handling would be overkill? -- Nick Roberts