All `*_s` combinators of Lwt_react eat exceptions silently

[rand00]

The E.*_s and S.*_s combinators all eat exceptions raised by the function-argument:

#!/usr/bin/env -S opam exec -- utop

#thread
#require "lwt"
#require "lwt.unix"
#require "lwt_react"

open Lwt.Syntax
open Lwt_react

let tick_e, tick_eupd = E.create ()
let tick_s = S.hold () tick_e

(*> Works*)
let e0 = tick_e |> E.map (fun _ -> failwith "error")

(*> No exception is printed - and program doesn't terminate*)
let e1 = tick_e |> E.map_s (fun _ -> failwith "error")

(*> Works*)
let e2 = tick_e |> E.map_p (fun _ -> failwith "error")
  
(*> No exception is printed - and program doesn't terminate*)
let e3 = tick_e |> E.fmap_s (fun _ -> failwith "error")

(*> No exception is printed - and program doesn't terminate*)
let s0 = tick_s |> S.map_s (fun _ -> failwith "error")

let rec feed_tick () = let* () = Lwt_unix.sleep 0.5 in tick_eupd (); feed_tick ()

let () = Lwt_main.run @@ loop () 

The exception is neither printed nor leading to program exit. From the source, this seems to be everywhere where Lwt_mutex.with_lock is used to wrap the given function

[rand00]

Same problem with the function given to E.from:

(*> No exception is printed - and program doesn't terminate*)
let e4 =
  let i = ref 0 in
  let feed () =
    if !i = 5 then failwith "five" else (
      incr i;
      let* () = Lwt_unix.sleep 0.5 in Lwt_io.printl "x"
    )
  in
  E.from feed

[rand00]

Ah - it's not Lwt_mutex that is the problem - it just delays the lambda for a bit, so the scheduler gets to run other threads before it. If you yield in map_p the same happens:

let e5 = tick_e |> E.map_p (fun _ -> let* () = Lwt.pause () in failwith "error")

None of the threads created by running the lambdas are registered anywhere - I think they should have their exceptions be passed to the Lwt.async_exception_hook. Lwt_react.E.of_stream already passes exceptions there - which is documented.

The documentation notes that E.from stops when an exception is thrown - but the silent ignore of exceptions is not documented for the other combinators - the chosen behaviour should be underlined in the documentation. The user can then e.g. wrap the lambdas body in Lwt.catch if more robust handling is needed.

A problem is that a future application of the lambda might want to know about previous errors - in which case one could want to manually stop this part of the FRP-graph. If stopping this part of the graph is not needed, a solution could be to wrap the lambda body with Lwt_result.catch together with fold_s.