Re: error handling

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

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

-anil