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,b3f788f59498d3af X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!n15g2000prd.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Exceptions and out procedure arguments (using GNAT GPL) Date: Tue, 19 Jun 2007 14:20:56 -0700 Organization: http://groups.google.com Message-ID: <1182288056.091791.248430@n15g2000prd.googlegroups.com> References: <79c673pq5htg508nkoi935n3udqg5ps7r8@4ax.com> <1182181497.595409.300500@a26g2000pre.googlegroups.com> <1182238493.512406.168820@o61g2000hsh.googlegroups.com> <1182266486.650797.262430@a26g2000pre.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1182288056 17247 127.0.0.1 (19 Jun 2007 21:20:56 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 19 Jun 2007 21:20:56 +0000 (UTC) In-Reply-To: User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: n15g2000prd.googlegroups.com; posting-host=66.126.103.122; posting-account=cw1zeQwAAABOY2vF_g6V_9cdsyY_wV9w Xref: g2news1.google.com comp.lang.ada:16245 Date: 2007-06-19T14:20:56-07:00 List-Id: On Jun 19, 1:07 pm, "Dmitry A. Kazakov" wrote: > On Tue, 19 Jun 2007 08:21:26 -0700, Adam Beneschan wrote: > > My gut feeling is that, in > > the abstract, a subprogram should either produce a result *or* > > (perhaps) raise an exception, but not both; in general, if your > > definition of a subprogram is that, under certain conditions, the > > subprogram will raise an exception AND the caller can expect a certain > > value to be returned (whether in an OUT parameter or an IN OUT or a > > global or in something pointed to by an access parameter or whatever) > > even though an exception is raised, the design is wrong. It's better > > to use an OUT status code of some sort in that case. > > I don't think this is a good advice. In my view a right design assumes that > whether an exception is propagated or not, the subprogram should not leave > anything in an undefined state. I think I agree with what you're saying, sort of. Leaving things in an undefined state (or worse, in an unusable state with dangling pointer references or something like that) is bad. 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. 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", but I realize that this is rather difficult for me to express precisely. -- Adam