Hi, you could define a helper like:

1
2
3
4
5
6
7
8
let AsyncStartLogged a =
    async {
        try
            do! a
        with e ->
            do! Server.LogException(e.Message, e?stack) // I will add proxy for Exception.Stacktrace
    }
    |> Async.Start

and use this everywhere instead of Async.Start.

By on 2/9/2017 2:09 PM ()

Hi AndrĂ¡s,

Thank you for the response.

It seems that in my case a problem wasn't Async.Start executed directly. In my situation exceptions that are inside View.Map (or perhaps other reactive constructs) are the problem.

I've reproduce the problem in this repository: https://github.com/kowalgta/websharper-async-uncaughtexception and exact line causing issue: https://github.com/kowalgta/websharper-async-uncaughtexception/blob/master/UncaughtException/Client.fs#L18

I will use your suggestion for View.Map and try to override it with the logging wrapper.

By on 2/15/2017 8:22 AM ()

Thanks, feel free to share further thoughts and suggestions!

I was thinking too to add more error catching in UI.Next but we decided against it because of performance overhead. But this makes the applications break badly when a function passed to View.Map throws an exception, as it breaks the entire loop in MarkReady so other mapped Views won't be updated. I have a stashed experiment of expanding UI.Next Snap values with failed states too, able to handle View.Map failures gracefully. Maybe I will revisit it, and possibly there could be a way to add it as a configurable feature, for example use it in Debug mode only.

By on 2/16/2017 2:54 AM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper