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!t-online.de!news-lei1.dfn.de!newsfeed.freenet.de!newsfeed01.chello.at!newsfeed.arcor.de!newsspool2.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> <6rw4k9rlnssv.1lwvk86ldjblo.dlg@40tude.net> Date: Tue, 23 Jan 2007 15:21:09 +0100 Message-ID: NNTP-Posting-Date: 23 Jan 2007 15:21:09 CET NNTP-Posting-Host: d91b7c16.newsspool2.arcor-online.net X-Trace: DXC=>>g0VEBf]nJA@P]\DA9EHlD;3YcB4Fo<]lROoRAFl8W>\BH3YB?]kgB\2[`UDUn9]M X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:8421 Date: 2007-01-23T15:21:09+01:00 List-Id: On Tue, 23 Jan 2007 02:28:12 -0500, Stephen Leake wrote: > "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. Oops, then you reject use of exceptions here. That would be a different discussion then. > 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. Good, let's drop that E-mail stuff, because sensors seem to be closer to both of us. > 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. I don't think so. From a system-wide perspective, yes, sure, but locally I have a problem with that. Let's consider: function "+" (X, Y : Sensor_Result_Type) return Value_Type; We have to discard this on the same reasons (if we had accepted them (:-)) and replace it with: function "+" (X, Y : Sensor_Result_Type) return Sensor_Result_Type; Now, before we would rush into developing a home-brewed IEEE arithmetic. May I ask you, how Quality_Type compose under "+"? I know what 1+2 is, but what is (1, Try_Again) + (2, Change_Battery)? (2, First_Change_Then_Try)? (:-)) > Note that the algorithm is not just skipped; it probably uses an > estimate based on past values. Yes, these are not exceptional states, they are parts of some composite value. Nobody would implement that using exceptions. It would be like file Read raising exception on each read character and returning EOF if there were no one. (:-)) Let's don't consider measurement errors and concentrate on hardware faults. > 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. OK, this is a third case. Timeouts are handled in a similar way. Before an exceptional state is entered one ignores the data/service quality assuming that everything is alright, because no reasonable estimation could be made anyway before the timeout expires. >> 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. Full agreement. But the mechanism of passing is very different. In case of exceptions it is fully transparent for the layers where the exception is being propagated unhandled. A big difference. >> 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. See the example with "+". >> 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? Actually your Sensor_Result_Type is exactly what I had in mind. >> 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. Consider it a protected object, with Get_Quality and Get_Value functions. (a middleware is a kind of bunch of such objects) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de