-2

I have a base framework designed to deal with errors generically; however, when the error occurs, I appear to not be catching it in my framework. The following code is a simplified version of what I'm trying to achieve:

class Program
{
    static void Main(string[] args)
    {
        RunMethod<decimal>(() =>
            {
                decimal x = 0;
                decimal y = 1 / x;
                return y;
            });

    }

    private static async Task<T> RunMethod<T>(Func<T> method)
    {
        try
        {
            var result = await TryRunningMehod<T>(method);
            return result;
        }
        catch (DivideByZeroException ex)
        {
            System.Diagnostics.Debug.WriteLine("Error");
            return default(T);
        }
    }

    private static async Task<T> TryRunningMehod<T>(Func<T> method)
    {
        var returnValue = await Task.Run<T>(method);
        return returnValue;
    }
}

What happens when you run the above code is it crashes on the divide by zero. I'm trying to make it write a debug message and continue.

I have break on unhandled exceptions only flagged.

My exceptions settings:

enter image description here

What the IDE looks like when it breaks:

enter image description here

Paul Michaels
  • 16,185
  • 43
  • 146
  • 269
  • 2
    Whatever you "flagged" is not what you think it is. My crystal ball says that you ticked the Thrown checkbox in the Debug > Exceptions dialog. Which makes the debugger stop when the exception is thrown, before it can reach a *catch* block. You'll need to address the real bug in this code, your program ends before the task can complete. – Hans Passant Jun 04 '15 at 13:44
  • I have checked more than once that I don't have that flag. And when the task ends is basically irrelevant in this example, because it errors - which is the purpose of the test (the code it's based on does await the function) – Paul Michaels Jun 04 '15 at 13:47
  • You aren't awaiting for `RunMethod` to finish, which means your application is already terminating by the time you divide by zero. – Panagiotis Kanavos Jun 04 '15 at 13:50

1 Answers1

0

You never await for RunMethod to finish executing so the application has no chance to catch and process the exception. It has already finished and is in the cleanup phase.

Simply change your code to :

RunMethod<decimal>(() =>
        {
            decimal x = 0;
            decimal y = 1 / x;
            return y;
        }).Wait();

and the exception handler will work as expected.

In fact, the compiler issues a warning about this. Tools like ReSharper will also complain and mark the call.

By making this change, execution will enter the exception handler. As it is, nothing will appear in the console but the word Error will appear in Visual Studio's Output window.

To show an error message in the console, the exception handler should change to:

    catch (DivideByZeroException ex)
    {
        Console.WriteLine("Error");
        return default(T);
    }
Panagiotis Kanavos
  • 120,703
  • 13
  • 188
  • 236
  • That makes no difference – Paul Michaels Jun 04 '15 at 13:59
  • What do you mean? Running this will result in execution entering the exception handler. Had you written `Console.WriteLine` instead of ` System.Diagnostics.Debug.WriteLine` you would see a message in the console. As it is, the message will appear in Visual Studio's Output window – Panagiotis Kanavos Jun 04 '15 at 14:05
  • I've ran it, and it doesn't. To be clear, I'm expecting the code to enter the catch bloc and then return without causing an error. As it stands, the debugger is breaking at the diver by zero error – Paul Michaels Jun 04 '15 at 14:08
  • Doesn't what? Running this code does enter the exception handler and does print the message. What did you try and what happened? – Panagiotis Kanavos Jun 04 '15 at 14:09
  • I tried everything that you suggested. Please see my latest edit for what happened. – Paul Michaels Jun 04 '15 at 14:16
  • 1
    Yes, that is what happens when an exception occurs. And then execution moves to the exception handler. – Panagiotis Kanavos Jun 04 '15 at 14:21