views:

512

answers:

5

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

+10  A: 

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)
    {

    }
Noah
COMException inherits ExternalException inherits SystemException inherits Exception. Unless there is something I am missing, this should not be the case of missing the catch, perhaps just adding he System.Exception catch?
Tom Anderson
COMException may inherit from System.Exception, but it's still not caught in the COM interop with System.Exception. I've done a lot of interop with AutoCAD and this drove me crazy for quite awhile since I was so used to using the catch all instead of specifying my exact exceptions.
Noah
woah hold the phone - are you serious!? Clearly you are but that's really surprising and really bad! Does this happen for any other ExternalException types?
Rory
I've only really played around with it in AutoCAD and I had to use Autodesk.AutoCAD.Runtime.Exception quite a bit, and this derives from System.Exception. I spent a few days trying to figure out why my catches were crashing AutoCAD, when I thought I was handling the exception properly.
Noah
Noah, if he'd used catch (Exception ex) {...} would it have caught the COMException, in your experience? ie Does the weirdness happen only when you don't specify any exception type, or does it always happen unless you specify COMException exactly?
Rory
Can you point to any further discussion or examples of this - I'm quite interested. thanks.
Rory
I could be totally wrong here, but in my experience, I've had to specify the COMException to catch it as the exception occurs in unmanaged code outside of the CLR. I'll try some googling to see what MS says. I'm sure they've devoted some articles on MSDN for this.
Noah
Well, it seems that MS quite vague about this but it's best practices (http://msdn.microsoft.com/en-us/library/seyhszts.aspx) say you should try to catch the exact exception that will be thrown... personally I only use the Interop exceptions when dealing with COM, otherwise I just just use a Generic System.Exception or nothing at all.
Noah
This may also be somewhat helpful in describing the entire exception process http://msdn.microsoft.com/en-us/library/6kzk0czb.aspx
Noah
Hmm... that still suggests using Exception should just catch everything. http://msdn.microsoft.com/en-us/library/9ztbc5s1.aspx describes how interop maps from HRESULTs to .net exceptions. Note there's no such thing as a COM exception: the runtime creates an Exception when an HRESULT indicates a problem. Well-known HRESULTs are mapped to specific Exception types, everything else results in a COMException. However, I know various crazy things do happen with interop so wouldn't be hugely surprised if something wacky like this did happen, but it would surely have to be regarded as a bug.
Rory
It could be a weird AutoCAD interop thing as well, I just kept getting COM errors that would crash AutoCAD until I started using their runtime Exception Class.
Noah
OK this is weird. i just had the issue of Exception not catching ComException. Very Weird
Simon
A: 

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.

Joe
+3  A: 

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.

Lasse V. Karlsen
+2  A: 

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?

Andrei Rinea
FYI, you *can* catch OutOfMemoryException. Whether you can successfully free up some memory at that time (release references to things) depends on your application.
Curt Nichols
Well yes, you technically can catch them but they will be rethrown by the CLR runtime once you exit the catch block on and on..
Andrei Rinea
A: 

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