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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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