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,b3f788f59498d3af X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!news.belwue.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Exceptions and out procedure arguments (using GNAT GPL) 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: <79c673pq5htg508nkoi935n3udqg5ps7r8@4ax.com> <1182181497.595409.300500@a26g2000pre.googlegroups.com> <1182238493.512406.168820@o61g2000hsh.googlegroups.com> <1182266486.650797.262430@a26g2000pre.googlegroups.com> <1182288056.091791.248430@n15g2000prd.googlegroups.com> Date: Wed, 20 Jun 2007 10:01:56 +0200 Message-ID: <1roxz9pqarixg.ykwxgyertwu2.dlg@40tude.net> NNTP-Posting-Date: 20 Jun 2007 09:59:06 CEST NNTP-Posting-Host: e32e8060.newsspool2.arcor-online.net X-Trace: DXC=GC>5HR^2lhU\9P[:DUn00QA9EHlD;3YcR4Fo<]lROoRQ8kF_7=eDeZI843S X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:16256 Date: 2007-06-20T09:59:06+02:00 List-Id: On Tue, 19 Jun 2007 14:20:56 -0700, Adam Beneschan wrote: > The kind of thing > I'd object to is, say, a procedure that reads a string from a file > into an OUT parameter, and then raises an exception if the string > doesn't conform to some syntax. Then, from the caller's point of > view, the procedure can *both* return valid (although inferior) output > *and* raise an exception, which I think would make things difficult to > understand for someone trying to read the code that calls the > procedure---I'd be scratching my head trying to figure out why, after > the caller has caught an exception in the procedure, is it still using > the value returned by the procedure? That's a case where an > additional OUT parameter to say "this data is malformed" would be > better. Oh yes, this is a great example. No, I am using exceptions here. When designing something like a recursive descent parser, I'm always use this pattern: function Get (Source : Source_Type) return Thing; when Get parses Thing (which can be as big as "package declarative region" or "subprogram body" etc) it advances Source to the position following the thing. When it fails, it propagates an exception and leaves Source in some definite state, because the exception can potentially be handled to allow compilation to continue and you cannot reasonably continue if you don't know where you are. To use return codes for hundreds of Get's would be extremely tedious and close to unreadable. > There's a subtle difference between saying "a procedure that > raises an exception shouldn't be counted on to produce valid output" > and "a procedure that raises an exception shouldn't leave undefined > random garbage lying around", Yes > but I realize that this is rather > difficult for me to express precisely. Actually I think that boils down to your stand point on exceptions vs. program correctness. Mine is that any exception shall be a valid (correct) outcome. In other words, exceptions are a subject of DbC, they aren't a vehicle of. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de