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!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!newsfeed2.telusplanet.net!newsfeed.telus.net!edtnps90.POSTED!023a3d7c!not-for-mail Sender: blaak@METROID Newsgroups: comp.lang.ada Subject: Re: Structured exception information References: From: Ray Blaak Organization: The Transcend Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 2007 18:14:14 GMT NNTP-Posting-Host: 208.66.252.228 X-Trace: edtnps90 1169230454 208.66.252.228 (Fri, 19 Jan 2007 11:14:14 MST) NNTP-Posting-Date: Fri, 19 Jan 2007 11:14:14 MST Xref: g2news2.google.com comp.lang.ada:8337 Date: 2007-01-19T18:14:14+00:00 List-Id: Stephen Leake writes: > Maciej Sobczak writes: > > Doesn't feel as type-safe as advertised. > > But you have not given an actual example where a string is not > a type-safe solution to the actual problem at hand. > > The only example you have given is "present the error to the user". In > that case, a string is precisely the correct type. A common example I run into is to have the exception contain user-level versus detailed information. The top exception handler will tend to present the user-level information as a popup dialog, whereas the detailed information will be logged for later analysis, sent out as a bug report, etc. Often the detailed information could have various numeric values, e.g. source locations for parse errors. Even if both the user and detailed information are simple strings, one still has two strings, and it is a pain to have to come up with an encoding scheme (e.g. xml) and parse them back out when handled. Usage should be able to be simple and direct. > If you look into the details of "structured exception handling" in > other languages and implementations, they have bugs, and fundamental > flaws in design. [...] > So if you find yourself fighting Ada to do something, you need to step > back and think more carefully about _why_ you are doing it that way. > Ada is telling you it is inherently unsafe. The usage I described above is perfectly safe and bug free in all other languages I use, even C++. It is also convenient. Ada's philosophy is "correct", but the convenience can certainly be improved in this area. Consider also that any serialization scheme into exception strings is itself more complex and thus more likely to be buggy. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul.