I take exception to the way Visual Studio 2010 handles exceptions

Columbus MCSD

This is a gripe and a question, maybe someone can help me Problem Scenario: I just upgraded to Visual Studio 2010 Professional. I noticed some wierd things happening and after troubleshooting came up with this scenario Create a C# Windows Form Application in Visual Studio 2005 Professional Create a C# Windows Form Application in Visual Studio 2010 Professional Identical code in each

namespace WindowsFormsApplication2
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
//throw new Exception("test");
}

    private void Form1\_Load(object sender, EventArgs e)
    {
        //throw new Exception("test");
    }
}

}

Visual Studio 2005 uncomment the 'throw' statement in the Form1 constructor. Visual Studio will report the exception and halt the code. uncomment the 'throw' statement in the Form1_Load event handler. Visual Studio will report the exception and halt the code Visual Studio 2010 uncomment the 'throw' statement in the Form1 constructor. Visual Studio will report the exception and halt the code. uncomment the 'throw' statement in the Form1_Load event handler. Visual Studio silently aborts the method and continues running the code This means that, in VS2010, in order to stop on , for example, a System.NullReferenceException that I threw, I have to check the "Thrown" box in the Exceptions configuration (cntrl+shift+E). Doing this causes it to stop on *every* System.NullReferenceException, even ones that are swallowed by a try/catch block. I want VS2010 to act like 2005. Halt on any Exception that isn't explicitly delt with by a try/catch block, even Exceptions that I throw myself. I don't get why it will halt on an explicit throw in the Forms constructor, but silently abort the method when thrown in the event handler. I find myself constantly reconfiguring the Exceptions config screen when something unexpected occurs (usually when an exception happens that I don't know about) Am I doing something wrong or is this just something I need to adapt to?

Rob Philpott

This sounds pretty odd. I'm sure there is no native difference in the way the two versions of Visual Studio handle exceptions in the debugger. Don't quite understand what you were saying about the exceptions configuration, but try this: In both environments, go to Exceptions configuration as you say (cntrl+shift+E). In both cases, there should be two columns of checkboxes 'Thrown' and 'User-unhandled'. If you've only got one column go to Tools->Options->Debugging->General and make sure 'Enable just my code' is chcked. Then, make sure the two columns in the two environments match.

Regards, Rob Philpott.

Columbus MCSD

Thanks for the reply :) You are correct when I'm talking about the "Exceptions Configuration" i'm referring to Dialog Box that you access via Cntrl+Alt+E (sorry I gave wrong shortcut in the original post) I verified using your method. Here's the strange bit. At home I have WIndows 7 64 bit, at work I have Windows 7 32 bit I just did a little test where i made a new C# WindowsApplication project. The work PC halted on the "throw new Exception()" in the Form1_Load handler, but the home PC did not.

Lost User

Sardaan Frostreaver wrote:

even ones that are swallowed by a try/catch block.

Do you seriously write code that swallows exceptions in production?

Columbus MCSD

While I appreciate what you're saying, in the interest of preventing a debate on exception handling, let's keep the scope in context

Lost User

ok, thanks.

Bernhard Hiller

Look at that link: http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/[^] Nice, isn't it?

Luc Pattyn

Very interesting material. Thanks. :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

Columbus MCSD

That's it! Here's the C# signatures to implement his solution

    // definition
    public const uint PROCESS\_CALLBACK\_FILTER\_ENABLED = 1;
    
    \[DllImport("kernel32.DLL")\]
    public static extern bool SetProcessUserModeExceptionPolicy(uint dwFlags);
    \[DllImport("kernel32.DLL")\]
    public static extern bool GetProcessUserModeExceptionPolicy(ref uint lpFlags);

    // usage
    uint dwFlags = 0;
    if (StormWindows.Win32Api.GetProcessUserModeExceptionPolicy(ref dwFlags))
    {
        SetProcessUserModeExceptionPolicy(dwFlags & ~PROCESS\_CALLBACK\_FILTER\_ENABLED);
    }

MicroVirus

Thank you SO much for this link. I was, as the article described, pulling my hair out why and how a first-chance unhandled exception caused my program to silently crash in debug mode.