0

I have problem that watch expression is immediately interrupted when it comes to property that may use other thread. I don't want to have message "The function evaluation requires all threads to run", but still, I would like to use debugger feature of not executing potentially "unsafe" and long lasting properties.

I saw that ThreadAbortException is thrown when entering expression in Immediate Window, so I tried to handle this exception and continue execution of Watch Window thread execution while evaluating. But it didn't work.

I have next situation:

public partial class DummyClassWithDebuglessProperties
{
    public static int countPrompt = 0;
    public static int countSuccess = 0;
    public static int countThreadAbortException = 0;

    #region Properties

    public string StringPropertyDebugFail
    {
        get
        {
            countPrompt++;
            Debugger.NotifyOfCrossThreadDependency();
            countSuccess++;
            return "complex";
        }
    }

    public string StringProperty
    {
        get
        {
            return "simple";
        }
    }

    public string AllProperties
    {
        get
        {
            string stringPropertyDebugFail = "";
            try
            {
                stringPropertyDebugFail = StringPropertyDebugFail;
            }
            catch (ThreadAbortException)
            {
                countThreadAbortException++;
                stringPropertyDebugFail = "failedReading";
                Thread.ResetAbort();
            }

            //expecting for watchWindow: simple, failedReading
            //expecting in regular execution: simple, complex
            return String.Format("{0}, {1}", StringProperty, stringPropertyDebugFail);
        }
    }

    #endregion Properties
}

Debugging in test method:

    [TestMethod]
    public void ReadProperties()
    {
        DummyClassWithDebuglessProperties dummyClassWithDebuglessProperties = new DummyClassWithDebuglessProperties();

        //Create watch for next
        //dummyClassWithDebuglessProperties.AllProperties;

        //breakpoint at the end.
    }

It seems that ThreadAbortException is handled, but Thread.ResetAbort() doesn't have success with recovering thread that should initialize expression in Watch Window and when leaving Catch block it is being rethrown like ResetAbort doesn't have effect. On the first evaluations of watches when reaching breakpoint, I have next situation:
Image - Initial try to read "unsafe" property

We see that property was prompted for reading and that ThreadAbortException occured. After clicking marked icon, "unsafe" reading is executed.
Image - Regular reading after button click

I'm interested for initial evaluation, is it possible to have evaluation such as:
simple, failedReading

Maybe Thread.ResetAbort() is ignored for Watch Window thread. Any ideas?

Related topics that are references:
Visual Studio during Debugging: The function evaluation requires all threads to run
Evaluation requires a thread to run temporarily. Use the Watch window to perform the evaluation

Community
  • 1
  • 1
Nemanja Avramovic
  • 31
  • 5
  • This method is useful to .NET Framework code, it helps to quickly fail a watch expression instead of the programmer having to wait for the deadlock to timeout. It is not useful to you, you already know that it can't work and that TAE is going to be thrown. – Hans Passant Nov 05 '15 at 22:34
  • @Hans: I gave simple example in question just to technically explain what is limitation that is preventing me to do what I want. In a real scenario, I want to read all properties from some object by reflection and to create single string result. I want to skip those properties which fail because of _Debugger.NotifyOfCrossThreadDependency();_ and I want to exclude them from the result. This is kind of helper for debugging, and it is **useful** if I can put such result in Watch Window. Please, tell me if my task is still not clear enough. – Nemanja Avramovic Nov 09 '15 at 16:47
  • Your task is clear enough, although you couldn't come up with a worse example snippet if you tried. That Debugger.NotifyOfCrossThreadDependency() does absolutely nothing to solve your problem is something that is still not clear enough to you. If a property getter needs code on another thread to run then you can't watch it, end of story. – Hans Passant Nov 09 '15 at 16:57
  • @Hans: The point is that I don't want to watch property that needs another thread to run, I want to skip it. _Debugger.NotifyOfCrossThreadDependency();_ is not to solve my problem, but to illustrate it. I don't know which property will make this call. It would be good if I could handle thrown exception in the catch block. But I couldn't and don't know how. It would be good if I could inspect somehow by reflection if property requires another thread to run before calling that property. But I don't know how. – Nemanja Avramovic Nov 09 '15 at 18:10

0 Answers0