32
votes

I'm looking for ideas on how to make RX more easily debuggable. It can be so very difficult to find the point of failure when a source is passed through combiners and throttles and publishes and such.

So far I've been doing similar things to what I do with complicated Enumerable chains - inserting Do() for tracing, adding a "name" field to an anonymous type part way through, grabbing stack traces sometimes.. But we have perhaps hundreds of producers and maybe thousands of consumers in our system and it's getting very hard to isolate problems.

What kinds of tricks do you have for debugging your RX usage?

2
Great question. I'm always struggling to debug my Rx code. - Tim
I strongly disagree with this question being casually closed by casperOne. I am looking for expertise in a very specific technology. This question will not likely result in "opinion, debate, arguments, polling, or extended discussion". - scobi
Not constructive? Maybe the question is not quite specific enough, but it's a highly valuable question. Oh well, back to the "why doesn't this code compile" questions. - Niall Connaughton
While this question may lead to some discussion, it seems like a reasonable question. The asker mentions specific debugging techniques that he tried and outlines why they aren't sufficient in specific circumstances. One would hope answers to this question would enumerate additional proven debugging techniques, wich would benefit readers of this site. Voting to re-open. @Scott Bilas: I think it would improve the question if you could clarify why in this your specific set of circumstances the techniques already tried make it "very hard to isolate problems". - njuffa
I am so glad that the voice of reason prevailed and the question was re-opened. - Tim Long

2 Answers

13
votes

I think a constructive discussion on this topic has been had on the Rx Forums in 2009.

Instead of adding adhoc Do operators into your queries, you would add a custom Log/Trace operator. This operator would capture the Subscription, Disposal, OnNext, OnError and OnCompleted events. Depending on your implementation it could just write to the console, use your favorite Logger library or even create ETW events for OS and Visual Studio integration.

public static class ObservableTrace
{
    public static IObservable<TSource> Trace<TSource>(this IObservable<TSource> source, string name)
    {
        int id = 0;
        return Observable.Create<TSource>(observer => 
        {
            int id1 = ++id;
            Action<string, object> trace = (m, v) => Debug.WriteLine("{0}{1}: {2}({3})", name, id1, m, v);
            trace("Subscribe", "");
            IDisposable disposable = source.Subscribe(
                v => { trace("OnNext", v); observer.OnNext(v); },
                e => { trace("OnError", ""); observer.OnError(e); },
                () => { trace("OnCompleted", ""); observer.OnCompleted(); });
            return () => { trace("Dispose", ""); disposable.Dispose(); };
        });
    }
}
12
votes

One important trick for catching Rx bugs is to retry debugging with first-chance exceptions enabled, this makes it way more likely that you'll get a real exception message instead of a rethrown one: