Re: best practice: error handling

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Tue, 31 May 2011 20:08:38 +0200, Jeffrey Carter  
<spam.jrcarter.not@spam.not.acm.org> a écrit:
> The correct way to handle this is for the function to return a variant  
> record:
>
> type Index_Result (Found : Boolean := False) is record
>     case Found is
>     when False =>
>        null;
>     when True =>
>        Index : Positive;
>     end case;
> end record;

That's an idiom I also use with SML (I feel to remember there is a  
dedicated name for that idiom, but I forget what it is this name), as  
access to the result is automatically constrained to whether or not the  
function succeed. But while this is good for request-like function (like  
get the item with this or that property), this come to be less handy when  
many and many functions or procedure return a common type may also return  
error, because you end to as many type definition.

Another case is the if-previous-succeed-then-go-on-else-bypass idiom.  
Multiple procedure get an in/out boolen parameter. If on input, the  
parameter is False, then the procedure bypass its own process, if the  
input parameter is True, the procedure do its job and set the parameter to  
False on output if ever it fails somewhere. This is a useful idiom with  
SPARK which does not allow exceptions. Combined with that strategy, a  
wrapper type would lead to a mess.

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
“c++; /* this makes c bigger but returns the old value */” [Anonymous]