Le 1 févr. 08 à 11:50, Till Varoquaux a écrit :

> While I think having clearer signatures is great,  I am still wary
> that this solution might prove too much of a constraint in some cases.
> I still think exceptions shouldn't be shunned so quickly. As their
> name clearly stipulates they should be used to handle exceptional
> cases, and sometimes the nature of what's an exceptional case is
> better left to the programmer's judgment (e.g. find). I believe that,
> when needed, both functions should be exposed in the interface (e.g.
> find and find_exn, or find and find_opt).

I stand behind the one liner that will make the error implicit if you  
want. Explicit first, implicit if you want to take the risk.  
Personnally I wouldn't make it implicit unless it is for an "assert  
false", but this is a matter of philosophy.

> Exceptions are an amazing tool to handle exceptional cases because
> they unwind stack the automatically.  This means that you don't have
> to constantly thing about propagating the errors manually.

I have nothing against exceptions per se. I also use them in my own  
programs. But I don't want libraries to force me to use them. Recall  
that the recommendation says nothing about client code. You can  
perfectly define your own exceptions to propagate the error up.

> I am also not very enthused by the use of the polymorphic variant
> versus a Haskell like [Left | Right] variant. I think the former can
> lead to hard to track errors (excerpt from the manual: "Beware also
> that some idioms make trivial errors very hard to find.") bringing an
> illusion of safety rather than safety itself. The latter also
> separates in clearer way the error cases from the success cases.

On the safety bit I think this is less true if you actually take care  
to close your variants. However I tend to agree on the clearer  
separation of cases. I added a request for comments on this at the end  
of the OSR page to standardize on [ `Value of ... | `Error of ... ]  
instead of [ `Value of ... | .... ].

Best,

Daniel