Re: Exceptions and out procedure arguments (using GNAT GPL)

[Fionn Mac Cumhaill <invisible@hiding.from.spam>]

On Tue, 19 Jun 2007 08:21:26 -0700, Adam Beneschan <adam@irvine.com>
wrote:

>On Jun 19, 12:34 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
>> On 19 Cze, 07:23, Fionn Mac Cumhaill <invisi...@hiding.from.spam>
>> 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.