为什么这个捕获所有块实际上并没有捕获所有

发布于 2024-07-22 06:16:44 字数 949 浏览 5 评论 0原文

代码相当简单——问题是 groupPath 字符串中存在无效字符(确切地说是“/”)。

我想做的(至少作为权宜之计)是跳过我无法获取 cn 的 DirectoryEntries --- 无论为什么。

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

为什么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");
}

附加观察结果: 该代码实际上位于自定义 RoleProvider 中,奇怪的是,如果我在一个简单的 winforms 应用程序中引用该提供程序,并使用相同的输入调用相同的方法,则 catch 块会完全执行其应该执行的操作。 我认为这表明关于 .NET 异常与 COM 异常的建议答案并不准确。 虽然我不明白为什么这段代码在从 WebDev 服务器执行时不会捕获

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

ι不睡觉的鱼゛ 2024-07-29 06:16:44

当您不指定要捕获的内容时,它默认为 .NET 异常。 您的异常出现在 COM 中,其中 .NET 未设置为捕获异常。 处理此问题的最佳方法是捕获 COM 异常,该异常应如下所示:

    try
    {

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

    }
    catch (System.Exception ex)
    {

    }

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

    }
酷炫老祖宗 2024-07-29 06:16:44

有三个原因:

  1. 运行时中存在错误
  2. 应用程序和/或线程作为某些执行代码的一部分而结束
  3. 您没有看到全貌

我个人投票支持 3,并且我进行了无数次调试会话我想知道为什么某些代码不处理我的异常,而实际上是 Visual Studio 配置为在所有引发的异常上停止,无论它们是否被捕获。

您是否尝试过要求程序继续在调试器中运行,然后看看它是否最终进入 catch 块?

另外,检查 Visual Studio 中的设置,转到“调试”->“异常”对话框,然后检查是否选中了任何“抛出”复选框。 如果有,那可能是你的问题。

当然,如果你在运行时看到这个问题,没有附加调试器,那么我不知道,除了上面的第 1 点和第 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.

心房的律动 2024-07-29 06:16:44

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

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

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.

洒一地阳光 2024-07-29 06:16:44

除了 COMException 之外,还有不要捕获的异步异常,例如:

  • OutOfMemoryException
  • StackoverflowException (不,这不是与此站点相关的笑话:) )
  • ThreadAbortException

您确定不是这种情况吗?

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?

回梦 2024-07-29 06:16:44

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

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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文