Re: error handling

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 13 Mar 2012, at 07:40, Raphael Proust wrote:

> 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.

Agreed; at a slightly higher level, I've been structuring my libraries 
into two halves:

- a pure protocol implementation that only uses the non-UNIX portions
of Lwt: specifically, Lwt_stream to handle blocking iteration. This library
should be reentrant, and have all its configuration passed into the
initialiser (i.e. no config files).

- a concrete client/server that uses the library and Lwt_io (and other
Unix modules) to build a real server. This can have config files and such.

In the library code, it's fine to have it be mostly non-Lwt (to make future
ports to something like Async possible), and use `wrap` as Raphael describes
to convert a normal OCaml exception into an Lwt one.  However, we must be
*very* careful to not let normal OCaml exceptions leak into an Lwt thread,
or else you end up with the dreaded 'random Not_found at the toplevel' result.

We do need a few more bits of scaffolding to make logging easier than it is
at the moment. I'm just about to upload my ocaml-workflow module (which is a 
sort of CIEL meets inetd and persistent threads) and we can figure it out 
from there.

-anil