[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: error handling

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.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.