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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Structured exception information Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <5e0owbs5cgtv$.kyfgnvskadxd.dlg@40tude.net> Date: Sun, 21 Jan 2007 11:40:35 +0100 Message-ID: <6rw4k9rlnssv.1lwvk86ldjblo.dlg@40tude.net> NNTP-Posting-Date: 21 Jan 2007 11:40:19 CET NNTP-Posting-Host: 50184dc8.newsspool2.arcor-online.net X-Trace: DXC=0EO_5`QKdEkUoRk[hk2WalA9EHlD;3Ycb4Fo<]lROoRaFl8W>\BH3YbRjYUQ23?7:oDNcfSJ;bb[eIRnRBaCd On Sat, 20 Jan 2007 10:04:07 -0500, Stephen Leake wrote: > "Dmitry A. Kazakov" writes: > >> On Fri, 19 Jan 2007 04:47:28 -0500, Stephen Leake wrote: >> >>> 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. >> >> What about presenting an information necessary for handling the exception >> to the handler? > > Ok, I would still like to see a precise example, not all this hand-waving. I wished to stay at the level of vagueness of "present the error to the user." (:-)) >> As a practical example, consider mail non-delivery. A returned mail plus >> traceback is the information to you, the handler from the exception point. > > To me, bounced emails are _not_ "exceptional" events in mail handling > systems; they are expected, even "normal". We agree on that. But that is not the problem we are discussing. Which simplified is whether an API procedure Send_Mail should add a non-string information to the Delivery_Error exception, or else pack it in a String. I prefer the former. > As for the failed > temperature sensor in another thread, out-of-band status information > is a cleaner way to handle this. I don't think so, that would make interfaces very clumsy. Further it is a bad design, because it eludes to face the problem by putting all the responsibility to deal with on the user's shoulders. The user of API must check the status later. This is a distributed overhead contaminating the code and violating the principle "here and now." Note, even if we considered a middleware layer, in which the sensor variable would indeed have a status field and a lot of other fields to make the internals working, even in this design, the argument would still hold. Because then, when accessing such variable object, one would again need an exception and an information about the status in it. Otherwise one would have quite nasty race condition issues when accessing such variables - you check the status, get preempted and then read a rubbish value. The point is, you have just moved the problem, you didn't solve it. And last but not least, it is an argument against exceptions in general and thus irrelevant here. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de