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!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!208.49.83.154.MISMATCH!uns-out.usenetserver.com!news.usenetserver.com!pc03.usenetserver.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Structured exception information References: <5e0owbs5cgtv$.kyfgnvskadxd.dlg@40tude.net> <6rw4k9rlnssv.1lwvk86ldjblo.dlg@40tude.net> From: Stephen Leake Date: Tue, 23 Jan 2007 02:28:12 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:afjqT5O12859UwJZ1PcgInV5VpA= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: af61245b5b912759e00d410903 Xref: g2news2.google.com comp.lang.ada:8410 Date: 2007-01-23T02:28:12-05:00 List-Id: "Dmitry A. Kazakov" writes: >>> 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. Good. > 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. Ah. Apparently you don't agree with me, or you missed my point. Since bounced emails are not exceptional events, they should not be handled by exceptions. Send_Mail should return status information, as much as it wants to, for bounced emails; it should _not_ raise an exception in this case. >> 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. Well, I'd need to see an actual interface, as part of a real system, to judge that. If you are talking about the sensor system, then I _have_ seen real examples of that, and it is not clumsy; it solves the problem of possibly failed sensors quite nicely. Basically, the result of any sensor read is a record: type Sensor_Result_Type is record Quality : Quality_Type; Value : Value_Type; end record; Any algorithm that deals with the sensor must be prepared for Quality to be Bad. Note that the algorithm is not just skipped; it probably uses an estimate based on past values. Only when the sensor is Bad for some finite time is it declared Permanently_Bad; then the system will switch to the backup sensor, or an algorithm that does not use that sensor. > 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. Say what? Whether the status information is passed in an 'out' parameter, or as part of a structured exception, or packed into an exception string, the user still has to deal with it. We are only discussing the parameter passing mechanism, not who is going to deal with the information. The same argument applies to the sensor system. > The user of API must check the status later. Why "later"? Since bouncing is expected, that status must be checked immediately; that's the point. For the sensor, the quality is packaged with the value, they are always examined together. > This is a distributed overhead contaminating the code and violating > the principle "here and now." I'm not familiar with that principle of code design. As a lifestyle, I've heard of it. > 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. I'm lost; which argument? > 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. Say what? Once the sensor has been read, all of the information is in an object of Result_Type; there is no race condition in reading the components of Result_Type. > The point is, you have just moved the problem, you didn't solve it. What "problem" are you trying to solve? > And last but not least, it is an argument against exceptions in general and > thus irrelevant here. I am arguing that exceptions should not be used when 'out' parameters are more appropriate. I am suggesting that in general, if you _need_ structured information as the result of a subprogram, passing it in an 'out' parameter is better than attaching it to an exception. But others have posted convincing cases where that is not true. And it appears the state of the art in exception mechanisms has improved, so it's not such a large problem as I thought it was. -- -- Stephe