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

Re: error handling

On 13 Mar 2012, at 09:53, Raphael Proust wrote:

> 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
> that?

Yeah, but last I checked, it hadn't been updated beyond an old version of
OCaml. I know Fabrice updated it, but I don't think it's working against
3.12 yet.

It would be a good use of it to check for exception 'barriers' between the
Lwt monad and not though...




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