The deferred analog of Core.Or_error
. It is exposed in std.ml as
Deferred.Or_error
.
The mental model for a function returning an 'a Deferred.Or_error.t
is that the
function never raises. All error cases are caught and expressed as an Error _
result. This module preserves that property.
Unfortunately, there is no way to enforce this property using the type system, so it
is more like a convention, or idiom. A function whose type ends with ... -> 'a
Deferred.Or_error.t
and still raises should be considered broken, and be fixed. With
that property in mind, Deferred.Or_error.List.iter
, for example, does not wrap the
execution of the given iter function f
inside a monitor. If one of these
application raises, the whole function Deferred.Or_error.List.iter
will raise as a
way to try to alert the developer that one the function is broken and needs attention
and fixing, rather than silently catching the error and converting it to
Or_error.Error
.
This behavior is consistent with Core.Or_error
's treatment of user-supplied
functions.
If you have to deal with a function that does not respect this idiom, you can use
Deferred.Or_error.try_with_join
to wrap its execution and enforce this property.
A monad is an abstraction of the concept of sequencing of computations. A value of type 'a monad represents a computation that returns a value of type 'a.
return v
returns the (trivial) computation that returns v.
ok_unit = return ()
try_with f
catches exceptions thrown by f
and returns them in the Result.t as an
Error.t. try_with_join
is like try_with
, except that f
can throw exceptions or
return an Error
directly, without ending up with a nested error; it is equivalent to
try_with f >>| Result.join
.
The option extract_exn
is passed along to Monitor.try_with ?extract_exn
and
specifies whether or not the monitor exn wrapper should be skipped (extract_exn:true
or kept (extract_exn:false
).