Re: [Caml-list] Extracting exception details (Async, Cohttp, Exn)

["Milan Stanojević" <milanst@gmail.com>]

On Fri, Nov 29, 2013 at 9:34 AM, Ollie Frolovs
<ollie.frolovs.2012@my.bristol.ac.uk> wrote:
> Hello list!
>
> I’m designing a function to query a web service and i am stuck trying to implement quality error handling/reporting. I have a specific question – how do i extract the “description” field from the Core’s Exn type?
>

There is no "description" field in Exn type.
The confusion here is that the exception you see is actually a wrapped
async exception. When async catches an exception, it wraps it up in a
different exception with more information for easier debugging.
Its definition is (you can see it at
https://github.com/janestreet/async_core/blob/master/lib/monitor.ml#L55)

module Exn_for_monitor = struct
  type t =
    { exn : exn;
      backtrace : string sexp_list;
      backtrace_history : Backtrace.t sexp_list;
      monitor : monitor;
    }
  with fields, sexp_of
end

exception Error_ of Exn_for_monitor.t with sexp

And that is what you see in your output.
To get the original exception you can use Monitor.extract_exn but that
gives you less information (but it might be ok in your particular
case)

> I’ve been experimenting in the top-level and i got stuck. My workflow with step by step explanations is below.
>
>
> First, i create a request, which i believe does not run just yet because it is “deferred”.
>
> utop # let result = try_with (fun () -> Cohttp_async.Client.get (Uri.of_string "http://127.0.0.2"));;
> val result : (Cohttp.Response.t * string Pipe.Reader.t, exn) Result.t Deferred.t = <abstr>
>
> Then, i “Deferred.map" the result at which point the Cohttp/Async library try to connect and (as desired) fail.

utop has some special support for async but I'm not sure exactly what
it does but I doubt it delays running a function.

In general when you have a function in async that returns a deferred,
you do kick off code that will eventually fill in the deferred that
you got back. It is not the case that only when you use that deferred
something happens. Just wanted to point this out to avoid
misconceptions about async.


> I had a look at Core’s documentation for Exn but its to_string returns the whole sexp converted into string so i am stuck :’(
>
> As a side question for someone familiar with Core – why does Exn.to_string return sexp in a string at all, it also has sexp_of_t, so i suppose one could evaluate Sexp.to_string @@ Exn.sexp_of_t e. I am surprised that i do not see a  function to extract the valuable description field from the exception and yet there is this apparent duplication of effort. Or am i talking non-sense?
>

As I said before, this is an issue with async wrapping the original
exception with some more data and then raising the new exception.

Exn.to_string gives you a sexp in a string precisely to avoid
duplication of effort. Otherwise we would need to write to_string and
sexp_of_t for each exception (basically having two preprocessors, one
for to_string and one for sexp). This way you just define your
exception and add "with sexp" and you get all the data in exception
when it's raised.

Hope this helps,
   Milan