Re: [MirageOS-devel] Error handling in Mirage

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 10 Jul 2014, at 12:17, Daniel Bünzli <daniel.buenzli@xxxxxxxxxxxx> wrote:

> 
> Le jeudi, 10 juillet 2014 à 11:47, Anil Madhavapeddy a écrit :
> 
>> Thoughts from others welcome -- I like Thomas' proposal and think that it
>> finds the sweet spot between forcing fully generic handling of polymorphic
>> variants and throwing exceptions everywhere.
> 
> If these exceptions are not supposed to be catched except at the toplevel 
> (i.e are really *exceptional*) the proposal is the right design according to 
> my book.

I think that's right. There's no sensible way to handle an unknown error.  Some 
of them, such as Unimplemented, could be caught locally in theory, but in 
practise it's quite surprising if you're using a device that simply hasn't 
implemented the featureset you want.

>  
> 
> Just one thing, the other exceptions you defined are very clear by reading 
> them but this one is suspicious:
> 
>    exception Unknown of string with sexp
> 
> What's the exact use case for that one ?  
> 
> * API misuse by a client ? that should be Invalid_argument
> * Internal error ? that should be an Assert_error  

This was a catch-all from when it was a polymorphic variant, and so I agree 
that it isn't needed any more.

That's an interesting point though -- is it better to use 
Pervasives.Invalid_argument, or define a local Invalid_argument?  The only bad 
implication I can think of using the Pervasives one is that you might 
accidentally catch one that is rippling up from a deeply nested source, which 
wouldn't happen if every defines their own exception values.

-anil
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel