Re: error handling

[Raphael Proust <raphlalou@xxxxxxxxx>]

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?

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


-- 
_______
Raphael