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!news4.google.com!out02a.usenetserver.com!news.usenetserver.com!in02.usenetserver.com!news.usenetserver.com!cycny01.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc06.POSTED!72fcb693!not-for-mail From: Fionn Mac Cumhaill Newsgroups: comp.lang.ada Subject: Re: Exceptions and out procedure arguments (using GNAT GPL) Message-ID: References: <79c673pq5htg508nkoi935n3udqg5ps7r8@4ax.com> <1182181497.595409.300500@a26g2000pre.googlegroups.com> <1182238493.512406.168820@o61g2000hsh.googlegroups.com> <1182266486.650797.262430@a26g2000pre.googlegroups.com> X-Newsreader: Forte Agent 4.2/32.1118 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 20 Jun 2007 15:15:49 GMT NNTP-Posting-Host: 71.164.246.37 X-Complaints-To: abuse@verizon.net X-Trace: trnddc06 1182352549 71.164.246.37 (Wed, 20 Jun 2007 11:15:49 EDT) NNTP-Posting-Date: Wed, 20 Jun 2007 11:15:49 EDT Xref: g2news1.google.com comp.lang.ada:16272 Date: 2007-06-20T15:15:49+00:00 List-Id: On Tue, 19 Jun 2007 08:21:26 -0700, Adam Beneschan wrote: >On Jun 19, 12:34 am, Maciej Sobczak wrote: >> On 19 Cze, 07:23, Fionn Mac Cumhaill >> wrote: >> >> > I eliminated the problem by modifying the offending procedure to not >> > raise exceptions. It now returns a status code in an additional out >> > argument. >> >> You might also introduce a temporary variable in the procedure to keep >> the "candidate" result and copy it into the relevant out parameter >> just before leaving the procedure (on the successful path). >> This would be better than changing the interface and error handling >> policy, which is very intrusive. > >But it might be the correct design anyway. 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. Sorry if I'm not >explaining this well---I don't always know what the common terminology >is for the things I'm thinking. Also, I'm not saying that this >necessarily applies to Fionn's program. > > -- Adam > The design needed to change in any case. The original Query was a function, not a procedure. It returned a handle to storage allocated to hold information about the result set returned by the query. That storage was allocated before the query was made. If no rows were returned, the exception was raised and the handle was lost. Given the design of the package, it might well have been possible to retrieve the handle, but that would have required producing a new function or procedure to find it. It is best not to lose it. With the design as I now have it, a loop to process looks like this pseudocode: Open a Query, return handle to result set while rows remain, process rows Close the query and deallocate storage designated by the handle. This is the simple and obvious way to do it, and works as expected even when the number of rows returned by the query is 0. It requires minimal revision to the original code to achieve this goal.