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

Re: error handling

On Tue, Mar 13, 2012 at 10:36 AM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> 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.

Wouldn't it be possible to use ocaml-exc (ocamlpro's uncaught
exception analyser) with (possibly a fake version of) Lwt to check for

The worst case involves replacing lwt's *.ml (not touching the *.mli at all).




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