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

[Adam Beneschan <adam@irvine.com>]

On Jun 19, 1:07 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
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