[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] Error handling in Mirage - request for comments!
On Mon, 2 Feb 2015 17:38:35 +0100, Daniel BÃnzli wrote: > > Le lundi, 2 fÃvrier 2015 Ã 01:45, Christophe Troestler a Ãcrit : > > > Since OCaml supports exceptions, I think there is no doubt that we > > must handle them effectively â not just wipe them under the carpet and > > let them abort the program/unikernel. > > That's a little bit like saying OCaml supports objects therefore we > should program with objects. The fact is that exceptions are almost > always misused in OCaml API design, most APIs should only ever raise > Invalid_argument and that's all; however that's really not what you > see in practice (I even remember having seen new APIs using that > insane Not_found exception...). You are in fact concurring with me! ;-) I did not say we must *use* exceptions, I said we must *handle* them because, precisely, there will be libraries that one wants/needs to use and one does not want that their (mis)use of exceptions causes havoc. No need to tell you that the difference between objects and exceptions is that the former cannot pop up as uninvited guests while the latter can come â as you mention â from any external library and disrupt the intended flow of the program. Hence the need to take them into account in the design. > Besides you don't have to abort the unikernel you can also install > some kind of global trap to handle uncaught exceptions (that's > e.g. the way fut works [1]). I think we are in agreement here â the ârunâ I proposed does precisely that â but sometimes this is too late, so âcatch_exnâ is also useful. > I think it's misguided to use them as an error reporting mechanism > we have much better ways and I highly disagree these better ways > will be ignored if you provide good combinators to handle them â > maybe sloppy programmers will ignore them, but then there's so much > you can do. The implicitness of exceptions will 1) also make sloppy > programmers ignore them but 2) make it harder to handle errors > correctly by non-sloppy programmers. Please lay down a concrete interface showing of what you mean. I think we all agree on the goal of writing robust software, we need to move the discussion to concrete proposals. Cheers, C. _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |