Why would this catch all block not in fact catch all

Question

The code is fairly simple --- the issue is that there is an invalid character in the groupPath string (a '/' to be exact).

What I'm trying to do (at least as a stop gap) is skip over DirectoryEntries that I can't get the cn for --- regardless of why.

However when I run this code the catch block doesn't run and I get instead: The server is not operational. and an unhandled System.Runtime.InteropServices.COMException.

Why would the catch block not catch this exception.

try
{
    using (DirectoryEntry groupBinding = new DirectoryEntry("LDAP://" + groupPath))
    {
        using (DirectorySearcher groupSearch = new DirectorySearcher(groupBinding))
        {

            using (DirectoryEntry groupEntry = groupSearch.FindOne().GetDirectoryEntry())
            {
                results.Add(string.Format("{0}", groupEntry.Properties["cn"].Value.ToString()));
            }
        }
    }
}
catch
{
    Logger.Error("User has bad roles");
}

Additional observations: The code is actually in a custom RoleProvider, and the curious thing is that if I reference, this provider in a simple winforms app, and call this same method with the same inputs the catch block does exactly what it's suppose to do. I think this suggests that the proposed answer concerning .NET exceptions versus COM exceptions is not accurate. Although I am at a loss to understand why this code would not catch when executed from the WebDev server

Answer 1

When you don't specify what to catch, it defaults to .NET exceptions. Your exception is in COM where .NET isn't set to catch the exception. The best way to deal with this is to catch the COM exception, which should look something like this:

    try
    {

    }
    catch (System.Runtime.InteropServices.COMException COMex)
    {

    }
    catch (System.Exception ex)
    {

    }

Answer 2

There's three reasons:

1. There's a bug in the runtime
2. The application and/or thread is ending as part of some of the code that executes
3. You're not seeing the whole picture

Personally I vote for 3, and I have had countless debugging sessions where I wonder why some piece of code isn't handling my exceptions, when in fact it was Visual Studio that was configured to stop on all thrown exceptions, regardless of whether they was caught or not.

Have you tried just asking the program to continue running in the debugger and see if it then ends up in the catch-block?

Also, check the setting in Visual Studio, go to the Debug->Exceptions dialog, and check if you got any of the Thrown checkboxes checked. If you have, that might be your problem.

Of course, if you see this problem at runtime, no debugger attached, then I have no idea, except for point 1 and 2 above.

And of course there's always point 4: The unknown.

Answer 3

A COMException thrown from within that try block will be caught and swallowed by the catch block.

Take a break, get yourself a coffee, put a breakpoint on the line "Logger.Error..." and try again.

Answer 4

Along COMException there are also asynchronus exceptions that DON'T get caught such as :

• OutOfMemoryException
• StackoverflowException (no, it's not a joke related to this site :) )
• ThreadAbortException

Are you sure that's not the case?

Answer 5

I had a similar problem. I was invoking a VB6 COM object that raised an error. The actual exception type turned out to be System.Reflection.TargetInvocationException. The innerException was set to the COMException. I ended up catching the System.Reflection.TargetInvocationException and checking the innerException