Re: [MirageOS-devel] Error handling in Mirage - request for comments!

[Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx>]

"In theory, explicitly listing all possible errors and forcing callers to 
consider them should result in more reliable code. In practice, it results in 
callers ignoring all errors."

This seems rather due to a lack of good, standarized, error handling 
combinators in mirage itself.

I'm really not sure that moving to more exceptions is a good thing especially 
since last time I had a look at it lwt's error handling and cancelation 
model/algebra it felt quite broken to me. I would rather say that the system 
should not use exceptions at all except for things that are not meant to be 
handled where the only action you take is to basically to abort the unikernel. 
In practice things like:

"Assume all code can raise exceptions, and that this must not break invariants 
or leak resources"

end up being a huge pain to code with. While it may make you feel the code is 
less involved in practice it is much more harder to reason about and to code 
against it correctly compared to using a well principled error monad. The 
latter will also be future proof to any concurrency mechanism you may want to 
use in the future.

Of course there may be a few cases were you want to be able to raise a globally 
defined exception that is not meant to be handled like Out_of_memory or in the 
block example you give. But I'm sure that you can count them on the finger of 
one hand and predefine them somewhere in mirage. 

Best,

Daniel



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