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

[Leo White <lpw25@xxxxxxxxx>]

Hi all,

As this discussion keeps on running, I thought I would add a couple of
thoughts:

- The problem with using exceptions for returning errors is that it
  becomes very difficult to distinguish between a dynamic error that is
  part of normal use (e.g. this network connection failed) from a
  programming error (e.g. Not_found accidently leaked from a use of
  List.find, an assert false triggering). This makes it hard to produce
  the correct behaviour in all cases: there are applications for which
  it would be better to kill everyting on detecting a programmer error
  rather than risk continuing in an unstable state.

- The problem with using Lwt.t as your error monad is that it becomes
  difficult to distiunguish between synchronous things that may return
  errors, asynchronous things that may return errors, and asynchornous
  things that should not return errors. It also seems tied up with the
  exception mechanism, which leads to the same problem as my previous
  point.

Personally, I would probably suggest that all Mirage modules/module
types include in their signatures:

  type error

  val pp_error : formatter -> error -> string

For cases where an error can reasonably be matched on and handled
specially, this should be exposed in the signature:

  type error = private [> `Foo of foo | `Bar of bar]

  val pp_error : formatter -> error -> string

Some nice combinators should be provided for using ('a, 'b) Result.t and
('a, 'b) Result.t Lwt. and for lifting an ('a, Foo.error) Result.t into
an ('a, Bar.error) Result.t.

Exceptions that escape their intended scope, should always be treated as
a programming error. The various "finally" functions for resources
should catch and reraise them, so that they can reach the outermost
scope which knows how best to deal with a programming error in the
particular application. The same goes for binding on an Lwt thread which
raised an exception or failed: it should cause an exception to be raised
to reach the outermost level.

The aim here is still to take the erlang-style kill the component that
failed and try again approach, but to ensure that there are two distinct
return paths for regular errors and programming errors. The secondary
aim is to have module signatures which give a clear indication of
intended use.

Regards,

Leo

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