Re: error handling

[Raphael Proust <raphlalou@xxxxxxxxx>]

On Tue, Mar 13, 2012 at 12:16 AM, Richard Mortier
<Richard.Mortier@xxxxxxxxxxxxxxxx> wrote:
> not the most exciting topic perhaps, but traditionally seems thorny.
>
> i'm trying to fix up ocaml-dns to be both a bit more correct and a bit more 
> robust.
>
> aiui, standard ocaml exceptions must not be allowed to propagate up to the 
> point where they hit an Lwt thread, as that is Bad.
>
> but there are a number of places in ocaml-dns -- and i expect that this will 
> not be uncommon -- where functions raise exceptions indicating things like 
> unparseable data (for whatever reason) has been received off the wire.
>
> what i'd normally do here would be to cause current processing to cease, to 
> return the unparseable data that caused the error so it can be logged, and 
> continue from some suitable point.
>
> my question is- what's the best way to do that under Lwt?
>
> i've tried the following but have some questions:
>
> 1/ using raise_lwt instead of raise means that every function in question -- 
> often these are subsidiary/helper functions Â-- need to start returning 'a 
> Lwt.t; does propagating the Lwt-ness all the way through matter at all, or do 
> i just need to start doing lots of ">>" to chain things together, rather than 
> using ";"?

It is not that big a matter in that not all lwt monad binds are actual
cooperation points (i.e. they don't always go through the scheduler,
i.e. they sometime are just as cheap as function calls).

It is a bit of a problem if someone wants to transform your code into
non-lwt one (e.g. to preemptive code or to async) as the algorithmic
and threading logics are mixed.

>
> 2/ making return types 'a option rather than 'a -- but this does not work to 
> return the unparseable bits

Or [('a, exn) either] if you prefer the exception monad to the option
one. (See http://blog.dbpatterson.com/post/9528836599 on this topic.)

>
> 3/ logging the error (via Lwt_json_logger no less!) -- but this does not let 
> me indicate that processing should stop at the appropriate place

IMHO this should be used additionally to exceptions. One is for
control flow management, the other for sys-admin purpose.

>
> 4/ leaving the standard "raise" exceptions in and trying to be careful to 
> catch them -- but this relies on me remembering all the entry points into the 
> library

This can be combined with the wrap function:
wrap f calls f and transform the result into a monad. If f raise an
exception, it is catched by Lwt.

You can use wrap at the interface between non-lwt parts and lwt parts.
It avoids the problem of 1/.


Cheers,
-- 
_______
Raphael