Re: best practice: error handling

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

Le Tue, 31 May 2011 16:01:19 +0200, milouz <a.michelizza@gmail.com> a  
écrit:

> Hi,
>
> I'm wondering about the best way to handle errors in Ada when calling
> a function/procedure that may fails.
>
> For example, when programming on Unix systems in C, the called
> functions usually return a zero or positive value on success and -1 on
> failure, while setting a global variable (errno) to give some
> informations about the failure.
>
> What's the best way to deal with that kind of error in Ada ?
> Throwing an exception ? Returning some error code ? Passing a special
> parameter ?...
I would say : at least the “errno” strategy, is not concurrency friendly.  
if two threads of a same process commit errors, then you are in trouble  
(one may overwrite the “errno” value of the other). Exceptions would be  
cleaner for such a case (providing your “errno” is not owned by threads).

Also depends on whether or not the errors you have in mind are more or  
less predictable. As two examples : a file write error is unpredictable, a  
user input error at the command line or at a use prompt, is on the  
contrary, predictable and should be supposed to be likely to happen. For  
the former, an exception would be the best in my opinion, and for the  
latter, either an exception or a result property could be OK; while I  
would personally be on favor of a result property, because a user error is  
potentially a normal result of a user input.


-- 
“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]