为什么这会抓住所有块实际上并不是全部

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

代码非常简单---问题是groupPath字符串中有一个无效字符(确切地说是'/')。

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.

我想要做的事情(至少作为一个停止差距)是跳过DirectoryEntries我无法获得cn - 无论为什么。

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.

但是,当我运行此代码时,catch块不会运行,而是我得到:服务器无法运行。和未处理的System.Runtime.InteropServices.COMException。

Why would the catch block not catch this exception.

为什么catch阻止不会捕获此异常。

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

附加观察:代码实际上是在一个自定义的RoleProvider中,好奇的是,如果我在一个简单的winforms应用程序中引用这个提供程序,并使用相同的输入调用这个相同的方法,那么catch块就会完全按照它的设想执行。我认为这表明有关.NET异常与COM异常的建议答案并不准确。虽然我无法理解为什么从WebDev服务器执行时此代码不会被捕获

5 个解决方案

#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:

如果未指定要捕获的内容,则默认为.NET异常。您的异常是在COM中,其中.NET未设置为捕获异常。处理这个问题的最好方法是捕获COM异常,它看起来像这样:

    try
    {

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

    }
    catch (System.Exception ex)
    {

    }

#2

There's three reasons:

原因有三:

There's a bug in the runtime

运行时中有一个错误

The application and/or thread is ending as part of some of the code that executes

应用程序和/或线程以某些执行代码的一部分结束

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.

我个人投票给3,我有无数的调试会话,我想知道为什么有些代码没有处理我的异常,实际上是Visual Studio被配置为停止所有抛出的异常,无论它们是否是抓住与否。

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

您是否尝试过让程序继续在调试器中运行并查看它是否最终在catch块中?

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.

另外,检查Visual Studio中的设置,转到Debug-> Exceptions对话框,然后检查是否选中了任何Thrown复选框。如果你有,那可能是你的问题。

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

当然,如果你在运行时看到这个问题,没有附加调试器,那么我不知道,除了上面的第1点和第2点。

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

当然,总有第四点:未知。

#3

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

从try块中抛出的COMException将被catch块捕获并吞没。

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

休息一下,给自己喝杯咖啡,在“Logger.Error ...”一行放一个断点,然后再试一次。

#4

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

沿着COMException,还有一些不会被捕获的异步异常,例如:

OutOfMemoryException
*Exception (no, it's not a joke related to this site :) )

*Exception(不,这不是与这个网站相关的笑话:))

ThreadAbortException

Are you sure that's not the case?

你确定不是这样吗?

#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

我有类似的问题。我正在调用一个引发错误的VB6 COM对象。实际的异常类型是System.Reflection.TargetInvocationException。 innerException设置为COMException。我最终捕获System.Reflection.TargetInvocationException并检查innerException

#1