1

I am attempting to run an async output that will last a large amount of time, and then closing the application during execution which causes the textbox to dispose. I thought this would be handled by simply returning in a try-catch statement, but VS still says there is an "unhandled" exception. Here is the code:

public void AppendOutput(string text)
    {
        var timeNow = DateTime.Now;

        if ((DateTime.Now - previousTime).Milliseconds <= 50) return;
        try
        {
            synchronizationContext.Post(new SendOrPostCallback(o =>
            {
                Output.AppendText((string)o);
            }), text);
        }
        catch(ObjectDisposedException e)
        {
            return;
        }

        previousTime = timeNow;
    }

Here is what happens in debug: What happens in debug

I there a reason why this is considered unhandled? I thought that's what try-catch was for. My understanding was that I could simply return because there's no need to handle exceptions for a program that is attempting to write to a textbox that has been disposed; the program should be ending the thread on its own. What is the correct way to deal with this problem?

Plaje
  • 65
  • 9
  • Are you sure you're not just breaking on all exceptions? – DavidG Jun 26 '20 at 13:07
  • I'm not sure what you mean. There's a lot of options there in the debugger and I don't see one that would specifically do what is happening here. I can see for sure that the exception that is happening is due to the program trying to access a disposed textbox. I have tried changing catch(ObjectDisposedException) to catch(Exception e) but that hasn't changed the outcome. – Plaje Jun 26 '20 at 13:14
  • 3
    That's happening because you're debugging. Expand the _Exception Settings_ option and select the _Don't break.. on this exception type_ (I can't remember the exact words). – devsmn Jun 26 '20 at 13:16
  • OK you're right. When I run the program normally outside of the debugger the exception is handled the way I expect. It also handles normally if I force stop with the debugger's red box instead of using the application's close button. I could disable the exception in the options, but is there not a way to deal with this in the program without disabling exceptions in VS? I feel like that isn't ideal. – Plaje Jun 26 '20 at 13:33
  • 1
    @Plaje `disable the exception in the options` The wording there may not be the best, but that only turns off *first-chance* exceptions in the debugger. With first-chance exceptions enabled, the debugger will break when the exception is thrown, before your code can catch it. See for example [Understanding Exceptions while debugging with Visual Studio](https://devblogs.microsoft.com/devops/understanding-exceptions-while-debugging-with-visual-studio/). – dxiv Jun 26 '20 at 17:23
  • @dxiv ah ok, that is not what I expected then from the description. Thanks – Plaje Jul 06 '20 at 11:34

1 Answers1

0

According to your description, you want to solve the abnormal problem that occurs during debugging.

You can add the following code in the initialization component function, as shown below:

public Form1()
        {
            InitializeComponent();
            Control.CheckForIllegalCrossThreadCalls = false;
        }

Result: enter image description here

Jack J Jun
  • 5,633
  • 1
  • 9
  • 27
  • Thanks, I tried this idea and the issue still occurred though. We discovered the issue only exists in the debugger so it is ok for now. – Plaje Jul 06 '20 at 12:58