blocks|key|1029184|text|你几乎永远不应该抓住顶级的例外。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1029185|在大多数情况下，您应该捕获和处理可能的最具体的异常，并且只有在有有用的东西可以使用它时才能这样做。|1029186|这个异常(haha)是，如果您捕获日志记录并重新抛出异常，则有时捕获顶级异常、记录异常并重新抛出它是可以的。|1029187|你几乎不应该抓住一个顶级的例外并吞下它。这是因为如果您捕捉到顶级异常，您并不真正知道您正在处理什么；绝对地，任何事情都可能导致异常，因此几乎可以肯定，您无法做任何能够正确处理每一个故障情况的操作。可能有一些失败，您可能只是想默默地处理和吞咽，但是仅仅是吞咽顶级的异常，您也会吞下一整堆本来应该向上抛出的代码来处理更高级别的异常。在您的代码示例中，您可能要做的是处理SQLException和log%2Bswallow；然后对于异常，记录并重新抛出它。这个盖住了你自己。您仍然在记录所有的异常类型，但是您唯一吞没的是相当可预测的SQLException，这表明您的SQL/数据库存在问题。|1029188|一种常见的做法是，只有在这一点上实际可以解决的每一个句柄异常，如果您不能在代码中解决它，那么就允许它向上冒泡。如果您不能在下一个级别上解决它，允许它继续上升。如果它未被处理到顶部，则向用户显示一个礼貌的应用程序(可能尝试快速自动保存)并关闭应用程序。允许应用程序在未处理的异常之后继续运行通常被认为更糟，因为您无法预测应用程序的状态，因为有异常发生。最好只是关闭和重新启动应用程序，以恢复到预期的状态。|1029189|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

You should almost never catch the top level Exception.

In most cases you should catch and handle the most specific exception possible and only if there is something useful you can do with it.

The exception (haha) to this is if you are catching for logging and re-throw the exception, then it is sometimes OK to catch a top level Exception, log it and rethrow it.

You should almost never catch a top level Exception and swallow it. This is because if you are catching a top level exception you don't really know what you are handling; absolutly anything could have caused it so you will almost certainly not be able to do anything that will handle every single failure case correctly. There probably are some failures that you may just want to silently handle and swallow, but by just swallowing top level Exceptions you'll also be swallowing a whole bunch that really should have been thrown upwards for your code to handle higher up. In your code example what you probably want to do is handle a SQLException and log+swallow that; and then for an Exception, log and rethrow it. This covers yourself. You're still logging all exception types, but your only swallowing the fairly predictable SQLException which indicates problems with your SQL/database.

A common practise is to only every handle exceptions that you can actually resolve at that point, if you can't resolve it at that point in code then you allow it to bubble upwards. If you can't resolve it at the next level up, allow it to continue up. If it reaches the top unhandled then display a polite appology to the user (perhaps attempt a quick autosave) and close the app. It's generally considered worse to allow an app to continue running after an unhandled exception because you can't predict the state of the application as something exceptional has occured. It's better just to shutdown and restart the app to get back to an expected state.

blocks|key|1029195|text|是,|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1029196|你应该从最具体的例外到最少，这样你就可以以一种适当的方式处理事情。|1029197|例如，如果您正在发出web请求，您应该首先捕获类似TimeOuts和404的内容，然后您可以通知最终用户他们应该重试(超时)和/或检查他们输入的URL。|1029198|然后你可以抓住一些不那么一般的东西，万一有更古怪的事情出了问题，然后回到正确的地方，抓住一个例外，在一些荒谬的事情发生的情况下。|1029199|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Yes,

You should catch from the most specific exception down to the least, so you can deal with things in an appropriate manner.

For example, if you were making a web request, you should catch things like TimeOuts and 404s first, then you can inform the end user they should retry (timeout) and/or check they URL they entered.

Then you could catch something less general, in case something a bit more wacky goes wrong, then fall right back to just catching an Exception in the case that something ridiculous happens.

blocks|key|1029207|text|作为最佳实践，您应该避免捕获异常并使用标志作为返回值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1029208|相反，您应该为预期的异常设计自定义异常并直接捕获这些异常。任何其他的东西都应该作为一个意外的例外出现。|1029209|在上面的示例中，您可能希望重新抛出一个更特定于业务的异常。|1029210|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

As a best practice, you should avoid catching Exception and using flags as return values.

Instead, you should design custom exceptions for expected exceptions and catch those directly. Anything else should bubble up as an unexpected exception.

In your example above, you may want to rethrow a more business specific Exception.

blocks|key|997936|text|您应该阅读一般的论文或google的“结构化异常处理”，更好地了解这个主题的全部内容，但是一般来说，捕捉每个异常都被认为是错误的做法，因为您不知道异常是什么(内存错误、内存不足、磁盘故障等等)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|997937|对于许多未知/意外的异常，您不应该允许应用程序继续。一般来说，您“捕捉”和处理的只有那些异常玩具已经确定，作为分析的方法，您正在编码的catch子句，该方法实际上可以创建，你可以做一些事情。唯一应该捕获所有异常的时间(捕捉异常x)是执行类似于记录它的操作，在这种情况下，您应该立即重新抛出相同的异常(不管它是什么)，这样它就可以将堆栈冒泡到某个一般的“未处理异常处理程序”，它可以向用户显示一条适当的消息，然后导致应用程序终止。|997938|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You should read a general paper or google &quot;Structured Exception Handling&quot; and get a better big picture of what this topic is all about, but in general, catching every exception is considered bad practice because you have no idea what the exception was (Memory fault, out of memory error, Disk failure, etc.).
And for many unknown/unexpected exceptions, you should not be allowing the application to continue. In general, you &quot;catch&quot; and handle only those exceptions toy have determined, as a result of an analysis of the method you are coding the catch clause for, that method can in fact create, and that you can do something about. The only time you should catch all exceptions (catch Exception x) is to do something like logging it, in which case you should immediately rethrow the same exception (whatever it was) so that it can bubble up the stack to some general &quot;Unhandled Exception Handler&quot; which can display an appropriate message to the user and then cause the application to terminate.

blocks|key|2524086|text|我同意代码分析工具。该规则的例外情况是，我在事件处理程序中捕获了一般异常，用户可以选择报告错误或忽略错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2524087|在您提供的示例中，我认为代码分析是正确的。如果你不能在那里处理一个特定的异常，你就不应该捕捉任何东西，让它达到最高的水平。这样，当您试图修复问题时，您将更容易地重新创建该问题。|2524088|您可以通过将连接字符串和ID值添加到异常的数据属性，并确保它也被记录下来，从而使示例变得更好。那样的话，你就会给自己一个复制错误的机会。|2524089|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I agree with the code analysis tool. My exception to the rule is that I catch the general exception in my event handlers and the user is given the option to report the error or to ignore it.

In the example you provide, I think the code analysis got it right. If you can't handle a specific exception right there, you shouldn't be catching anything at all and let it bubble up to the highest level. That way you'll have a much easier time recreating the issue when you try to fix it.

You could make your example better by adding the connection string and the ID value to the exception's Data property and be sure it is logged as well. That way you give yourself a fighting chance at reproducing the error.

blocks|key|1030620|text|看一看Krzysztof+Cwalina的这篇文章，我发现这篇文章对于理解何时捕获或忽略异常非常有帮助：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1030621|如何设计异常层次结构|offset|length|1030622|它描述的关于设计异常层次结构的所有原则在决定何时捕获、抛出或忽略异常时也是适用的。他将例外情况分为三组：|1030623|使用错误，例如DivideByZeroException，它指示代码中的错误；您不应该处理这些错误，因为可以通过更改代码来避免这些错误。|unordered-list-item|style|BOLD|CODE|1030624|逻辑错误，例如FileNotFoundException，您需要处理这些错误，因为您不能保证它们不会发生。(即使您检查文件是否存在，在读取文件之前，仍然可以在这一秒内删除它。)|1030625|系统故障(如OutOfMemoryException+)，您无法避免或处理。|1030626|entityMap|0|LINK|mutability|MUTABLE|url|http://blogs.msdn.com/kcwalina/archive/2007/01/30/ExceptionHierarchies.aspx^0|0|0|A|0|0|0|0|4|7|L|0|0|4|7|L|0|0|4|6|K|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@]|9|@$D|11|E|12|1|13]]|A|$]]|$1|F|3|G|5|6|7|14|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|15|8|@$D|16|E|17|K|L]|$D|18|E|19|K|M]]|9|@]|A|$]]|$1|N|3|O|5|J|7|1A|8|@$D|1B|E|1C|K|L]|$D|1D|E|1E|K|M]]|9|@]|A|$]]|$1|P|3|Q|5|J|7|1F|8|@$D|1G|E|1H|K|L]|$D|1I|E|1J|K|M]]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|S|$T|$5|U|V|W|A|$X|Y]]]]

Have a look at this article by Krzysztof Cwalina, which I've found very helpful in understanding when to catch or ignore exceptions:

<a href="http://blogs.msdn.com/kcwalina/archive/2007/01/30/ExceptionHierarchies.aspx" rel="noreferrer">How to Design Exception Hierarchies</a>

All the principles it describes about designing exception hierarchies are also applicable when deciding when to catch, throw, or ignore exceptions. He divides exceptions into three groups:

<ul>
<li>Usage errors, such as <code>DivideByZeroException</code>, which indicate errors in code; you shouldn't handle these because they can be avoided by changing your code.</li>
<li>Logical errors, such as <code>FileNotFoundException</code>, which you need to handle because you can't guarantee they won't happen. (Even if you check for the file's existence, it could still be deleted in that split-second before you read from it.)</li>
<li>System failures, such as <code>OutOfMemoryException</code>, which you can't avoid or handle.</li>
</ul>

blocks|key|2524220|text|我同意，一般来说，你应该只捕捉你期待的异常，并且理解如何处理。有几个我经常不这样做的例子：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2524221|如前所述，如果我捕获了一些有用的信息来记录，然后重新抛出。|ordered-list-item|2524222|如果我正在执行异步操作，例如在工作线程中处理排队的消息或作业，并且希望捕获异常，以便在不同的上下文中重新抛出。我还经常在这里使用一个丑陋的黑客，它使CLR附加堆栈跟踪信息，因此在新上下文中重新抛出时不会丢失它。|2524223|如果我正在处理一个孤立的任务或操作，并且可以通过关闭任务来处理异常，而不需要关闭整个应用程序。我经常希望，对于真正致命的异常(如OutOfMemoryException)，有一个顶级的异常，因为我一直忽略这些异常。正确的处理方法是在自己的AppDomain中运行孤立的任务，但我还没有足够的时间在项目上实现这个任务。|2524224|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|M|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|N|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|O|8|@]|9|@]|A|$]]]|J|$]]

I agree that, in general, you should only catch exceptions you're expecting and understand how to handle. A few cases where I often don't do this:

<ol>
<li>As mentioned above, if I'm capturing some sort of useful information to log and then rethrow.</li>
<li>If I'm performing an asynchronous operation, such as handling queued messages or jobs in a worker thread, and I want to catch the exception for rethrowing in a different context. I also often use an ugly hack here that tricks the CLR into appending stack trace information, so that it's not lost when rethrowing in the new context.</li>
<li>If I'm working with an isolated task or operation and I can handle the exception by shutting down the task, without shutting down the whole application. I often wish here that there were a top-level exception for truly fatal exceptions (like OutOfMemoryException), as I've been ignoring these. The proper way to handle this would be to run the isolated task in its own AppDomain, but I haven't had the available schedule time to implement this on a project yet.</li>
</ol>

This question comes from a code analysis run against an object I've created. The analysis says that I should catch a more specific exception type than just the basic Exception.

Do you find yourself using just catching the generic Exception or attempting to catch a specific Exception and defaulting to a generic Exception using multiple catch blocks?

One of the code chunks in question is below:

<pre><code>internal static bool ClearFlags(string connectionString, Guid ID)
{
 bool returnValue = false;
 SqlConnection dbEngine = new SqlConnection(connectionString);
 SqlCommand dbCmd = new SqlCommand("ClearFlags", dbEngine);
 SqlDataAdapter dataAdapter = new SqlDataAdapter(dbCmd);

 dbCmd.CommandType = CommandType.StoredProcedure;
 try
 {
 dbCmd.Parameters.AddWithValue("@ID", ID.ToString());

 dbEngine.Open();
 dbCmd.ExecuteNonQuery();
 dbEngine.Close();

 returnValue = true;
 }
 catch (Exception ex)
 { ErrorHandler(ex); }

 return returnValue;
}
</code></pre>

Thank you for your advice

EDIT: Here is the warning from the code analysis

Warning 351 CA1031 : Microsoft.Design : Modify 'ClearFlags(string, Guid)' to catch a more specific exception than 'Exception' or rethrow the exception

Catching specific vs. generic exceptions in c#

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

这个问题来自于针对我创建的对象运行的代码分析。分析表明，我应该捕获一种更具体的异常类型，而不仅仅是基本异常。您是否发现自己只是使用捕获泛型异常，还是试图捕获特定的异常，并使用多个catch块默认为泛型异常？所讨论的代码块之一如下：internal static bool ClearFlags(string connec...

问在c#中捕获特定的和一般的异常
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在c#中捕获特定的和一般的异常EN