Re: error handling

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

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

ah- thanks, i thought that might be the case :)

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

yup, true.  (would there be benefits of moving to async cf lwt other than that 
it's in core?)

>> 2/ making return types 'a option rather than 'a -- but this does not work to 
>> return the unparseable bits
> 
> Or [('a, exn) either] if you prefer the exception monad to the option
> one. (See http://blog.dbpatterson.com/post/9528836599 on this topic.)

hm- interesting, thanks.

>> 3/ logging the error (via Lwt_json_logger no less!) -- but this does not let 
>> me indicate that processing should stop at the appropriate place
> 
> IMHO this should be used additionally to exceptions. One is for
> control flow management, the other for sys-admin purpose.

yes, agree - i was just trying out a bunch of different things i came across :)

>> 4/ leaving the standard "raise" exceptions in and trying to be careful to 
>> catch them -- but this relies on me remembering all the entry points into 
>> the library
> 
> This can be combined with the wrap function:
> wrap f calls f and transform the result into a monad. If f raise an
> exception, it is catched by Lwt.
> 
> You can use wrap at the interface between non-lwt parts and lwt parts.
> It avoids the problem of 1/.

ok- that makes sense - will give it a go.

-- 
Cheers,

R.


This message and any attachment are intended solely for the addressee and may 
contain confidential information. If you have received this message in error, 
please send it back to me, and immediately delete it.   Please do not use, copy 
or disclose the information contained in this message or in any attachment.  
Any views or opinions expressed by the author of this email do not necessarily 
reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.