Re: [Caml-list] Preferred use of Invalid_argument and Failure

["Michaël Le Barbier" <michael.le_barbier@laposte.net>]

Xavier Leroy <Xavier.Leroy@inria.fr> writes:

> The convention that the standard library tries to follow is this.
>
> Invalid_argument is very much like a failed assertion: it indicates
> that something is wrong in the program itself, i.e. negative character
> positions in string functions.  Most programs will not catch
> Invalid_argument, treating as a fatal error.  Others will catch it,
> but only to enter a piece of generic "recover from unexpected error"
> code.
>
> Failure, on the other hand, signals errors that can happen in normal
> runs of the code.  For instance, you're converting a user-provided
> string to a number, and the string does not represent a number.  It is
> expected that the client code catches Failure and recovers gracefully,
> e.g. by asking for the number again, or producing a precise "syntax
> error" message.
>
> I recommend the use of Invalid_argument to report "should never
> happen" conditions at the boundary between library functions and user
> code.  On the other hand, the "Failure" exception is a bit of a legacy
> from earlier designs (Caml Light and even the original LeLisp-based
> Caml), and often is not the best way to report "normal error"
> conditions: instead, you could consider defining your own exceptions
> as Alain suggested, or even have your functions return "option" types
> instead of raising exceptions.

Thank you very much for your description of the error reporting scheme
used in the standard library, you made the things very clear.

Following your joined advices with Alain Frisch, I will rethink error
reporting scheme in that library to provide more accurate error
diagnostics. Accurate errors are clearly more useful than vague ones.

I suppose the ``right thing to do'' depends greatly of the application
type. Specifically, I am working on a program that do scientific
computations, and I am very interesting in getting a precise
description of parameters that crashed my program: throwing exception
seems a convenient way to provide this feedback.

Thanks again to all contributors for their valuable advices.
-- 
Cheers,
Michaël