blocks|key|3150677|text|异常代价很高，但却是必要的。您不需要将所有内容都包装在try+catch中，但您确实需要确保最终总是捕获到异常。这在很大程度上取决于你的设计。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3150678|如果让异常上升也可以的话，不要重新抛出。永远不要让错误不经意地过去。|3150679|示例：|3150680|void+Main()
{
++try+{
++++DoStuff();
++}
++catch(Exception+ex)+{
++++LogStuff(ex.ToString());
++}

void+DoStuff()+{
...+Stuff+...
}|code-block|syntax|javascript|3150681|如果DoStuff出了问题，您无论如何都会希望它退出。异常将抛出到main，您将在ex的堆栈跟踪中看到一系列事件。|3150682|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|R|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Exceptions are expensive but necessary. You don't need to wrap everything in a try catch but you do need to ensure that exceptions are always caught eventually. Much of it will depend on your design. 

Don't re-throw if letting the exception rise will do just as well.
Never let errors pass unnoticed.

example:

<pre><code>void Main()
{
 try {
 DoStuff();
 }
 catch(Exception ex) {
 LogStuff(ex.ToString());
 }

void DoStuff() {
... Stuff ...
}
</code></pre>

If DoStuff goes wrong you'll want it to bail anyway. The exception will get thrown up to main and you'll see the train of events in the stack trace of ex.

blocks|key|360865|text|我喜欢这样的哲学，即不捕获任何我不打算处理的东西，无论在我的特定上下文中处理意味着什么。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360866|我讨厌看到这样的代码：|360867|try
{
+++//+some+stuff+is+done+here
}
catch
{
}|code-block|syntax|javascript|360868|我经常看到这种情况，当有人“吃掉”异常时，很难发现问题。我的一位同事就是这样做的，它最终往往会成为一系列问题的贡献者。|360869|如果我的特定类需要做一些事情来响应异常，但问题需要冒泡出来，无论如何调用它发生的方法，我都会重新抛出。|360870|我认为代码应该是主动编写的，异常应该是针对异常情况的，而不是为了避免测试条件。|360871|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

I like the philosophy of not catching anything I don't intend on handling, whatever handling means in my particular context.

I hate it when I see code such as:

<pre><code>try
{
 // some stuff is done here
}
catch
{
}
</code></pre>

I have seen this from time to time and it is quite difficult to find problems when someone 'eats' the exceptions. A coworker I had does this and it tends to end up being a contributor to a steady stream of issues.

I re-throw if there is something that my particular class needs to do in response to an exception but the problem needs to be bubbled out to however called the method where it happened.

I think code should be written proactively and that exceptions should be for exceptional situations, not to avoid testing for conditions.

blocks|key|3150752|text|我正要离开，但我会简要介绍一下在哪里使用异常处理。当我返回时，我将尝试解决您的其他问题:)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3150753|3150754|显式检查代码周围的所有已知错误conditions*|ordered-list-item|3150755|Add尝试/捕获如果您不确定是否能够处理所有情况|3150756|如果您正在调用的.NET接口抛出异常|3150757|在代码周围添加尝试/捕获如果它超出了复杂性阈值|3150758|在代码周围添加尝试/捕获如果为了健康检查:您断言这种情况永远不应该发生|3150759|<代码>H111作为一般规则，我不使用异常作为返回代码的替代。这对.NET来说很好，但对我来说不是。我对这条规则有例外(哈哈)，这也取决于你正在工作的应用程序的架构。|3150760|*在合理范围内。没有必要检查是否宇宙射线击中了你的数据，导致了几个比特的翻转。对于工程师来说，理解什么是“合理”是一项后天技能。这很难量化，但很容易直觉。也就是说，我可以很容易地解释为什么我在任何特定实例中使用try/catch，但我很难向另一个人灌输同样的知识。|3150761|作为一个人，我倾向于远离严重的基于异常的架构。try/catch本身不会对性能造成影响，当抛出异常时，性能就会受到影响，代码可能需要遍历调用堆栈的几个级别，然后才能处理它。|3150762|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|10|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|11|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|12|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|13|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|14|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|U|$]]

I'm just on my way out but will give you a brief run down on where to use exception handling. I will attempt to address your other points when I return :)

<ol>
<li>Explicitly check for all known error conditions*</li>
<li>Add a try/catch around the code if your are unsure if you were able to handle all cases</li>
<li>Add a try/catch around the code if the .NET interface you are calling throws an exception</li>
<li>Add a try/catch around the code if it crosses a complexity threshold for you</li>
<li>Add a try/catch around the code if for a sanity check: You are asserting THIS SHOULD NEVER HAPPEN</li>
<li>As a general rule, I do not use exceptions as a replacement for return codes. This is fine for .NET, but not me. I do have exceptions (hehe) to this rule though, it depends on the architecture of the application your are working on as well.</li>
</ol>

*Within reason. There is no need to check to see if say a cosmic ray hit your data causing a couple bits to get flipped.
Understanding what is "reasonable" is an acquired skill for an engineer. It's hard to quantify, yet easy to intuit. That is, I can easily explain why I use a try/catch in any particular instance, yet I am hard pressed to imbue another with this same knowledge.

I for one tend to steer away from heavily exception based architectures. try/catch doesn't have a performance hit as such, the hit comes in when the exception is thrown and the code might have to walk up several levels of the call stack before something handles it.

blocks|key|3150820|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3150821|我应该在什么时候重新抛出异常？|blockquote|3150822|3150823|3150824|无处不在，但最终用户的方法...like按钮点击处理程序|3150825|3150826|我是否应该尝试建立某种中央错误处理机制？|3150827|3150828|3150829|我写了一个日志文件。对于WinForm应用程序来说非常简单|3150830|3150831|与抢先测试磁盘上的文件是否存在相比，处理可能抛出的异常是否会对性能造成影响？|3150832|3150833|3150834|我不确定这一点，但我相信这是一个很好的做法来处理例外情况……我的意思是，您可以询问文件是否存在，以及它是否抛出FileNotFoundException|3150835|3150836|是否应该将所有可执行代码都包含在try-catch-finally块中？|3150837|3150838|3150839|是的|3150840|3150841|在某些情况下，空的catch块是可以接受的吗？|3150842|3150843|3150844|是的，假设你想显示一个日期，但是你不知道该日期是如何存储的(dd/mm/yyyy，mm/dd/yyyy等)，你尝试tp解析它，但如果失败了，就继续...如果它与你无关...我会说是的，有|3150845|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|1B|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|1C|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|1D|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|1E|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|1F|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|1G|7|@]|8|@]|9|$]]|$1|I|3|J|4|C|6|1H|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|1I|7|@]|8|@]|9|$]]|$1|L|3|-4|4|5|6|1J|7|@]|8|@]|9|$]]|$1|M|3|N|4|5|6|1K|7|@]|8|@]|9|$]]|$1|O|3|-4|4|5|6|1L|7|@]|8|@]|9|$]]|$1|P|3|Q|4|C|6|1M|7|@]|8|@]|9|$]]|$1|R|3|-4|4|5|6|1N|7|@]|8|@]|9|$]]|$1|S|3|-4|4|5|6|1O|7|@]|8|@]|9|$]]|$1|T|3|U|4|5|6|1P|7|@]|8|@]|9|$]]|$1|V|3|-4|4|5|6|1Q|7|@]|8|@]|9|$]]|$1|W|3|X|4|C|6|1R|7|@]|8|@]|9|$]]|$1|Y|3|-4|4|5|6|1S|7|@]|8|@]|9|$]]|$1|Z|3|-4|4|5|6|1T|7|@]|8|@]|9|$]]|$1|10|3|11|4|5|6|1U|7|@]|8|@]|9|$]]|$1|12|3|-4|4|5|6|1V|7|@]|8|@]|9|$]]|$1|13|3|14|4|C|6|1W|7|@]|8|@]|9|$]]|$1|15|3|-4|4|5|6|1X|7|@]|8|@]|9|$]]|$1|16|3|-4|4|5|6|1Y|7|@]|8|@]|9|$]]|$1|17|3|18|4|5|6|1Z|7|@]|8|@]|9|$]]|$1|19|3|-4|4|5|6|20|7|@]|8|@]|9|$]]]|1A|$]]

<blockquote>
 When should I re-throw an exception?
</blockquote>

Everywhere, but end user methods... like button click handlers

<blockquote>
 Should I try to have a central error-handling mechanism of some kind?
</blockquote>

I write a log file... pretty easy for a WinForm app

<blockquote>
 Do handling exceptions which might be thrown have a performance hit compared with pre-emptively testing things like whether a file on disk exists?
</blockquote>

I'm not sure about this, but I believe it is a good practice to thow exceptions... I mean you can ask whether a file exists and if it doesn't throw a FileNotFoundException

<blockquote>
 Should all executable code be enclosed in try-catch-finally blocks?
</blockquote>

yeap

<blockquote>
 Are there any times when an empty catch block might be acceptable?
</blockquote>

Yes, let's say you want to show a date, but you have no clue how that date was stores (dd/mm/yyyy, mm/dd/yyyy, etc) you try tp parse it but if it fails just keep going... if it is irrelevant to you... I would say yes, there is

blocks|key|360944|text|我很快就学会了一件事，那就是用-catch块把与我的程序流(即文件系统、数据库调用、用户输入)之外的所有与交互的代码块完全封闭起来。Try-catch可能会对性能造成影响，但通常在代码中的这些地方，它不会被注意到，而且它会以安全的方式为自己买单。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|360945|我在用户可能会做一些不是真正“不正确”的事情的地方使用了空的catch-block，但它可以抛出一个exception...an示例，该示例出现在GridView中如果用户DoubleCLicks左上角的灰色占位符单元格，它将触发CellDoubleClick事件，但该单元格不属于一行。在这种情况下，你实际上不需要发布一条消息，但如果你没有捕捉到它，它将抛出一个未处理的异常错误给用户。|360946|entityMap^0|F|30|0|0|5E|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

The one thing I learned very quickly was to enclose absolutely every chunk of code that interacts with anything outside the flow of my program (i.e. File System, Database Calls, User Input) with try-catch blocks. Try-catch can incur a performance hit, but usually in these places in your code it won't be noticeable and it will pay for itself with safety. I have used empty catch-blocks in places where the user might do something that isn't really "incorrect", but it can throw an exception...an example that comes to mind is in a GridView if the user DoubleCLicks the gray placeholder cell on the top-left it will fire the CellDoubleClick event, but the cell doesn't belong to a row. In that case, you dont really need to post a message but if you don't catch it it will throw an unhandled exception error to the user.

blocks|key|3363859|text|有一个很棒的代码CodeProject+article+here。以下是几个亮点：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3363860|3363861|做好最坏的打算*|unordered-list-item|3363862|及早检查|3363863|不信任外部数据异常唯一可靠的设备是:视频、鼠标和keyboard.|3363864|Writes可能出现故障，太安全了<|3363865|>H213|3363866|不要抛出新的异常信息将重要的异常信息放在消息字段|3363867|为每个thread|3363868|Generic+|3363869|3363870|+exception+()；切勿在每个线程中只记录一次Exception.Message!|3363871|Don't捕获(异常)不要吞咽exceptions|3363872|Cleanup代码应放入最终块中使用"using“everywhere|3363873|Don't+return+special+values+on+error+conditions|3363874|Don't+resource|3363875|Don't+exceptions+ignored|3363876|Don't+|3363877|+exceptions+|3363878|ignored|3363879|Don‘t|3363880|+exception处理作为从方法返回信息的手段使用exception|3363881|error不应为ignored|3363882|Don’t的错误清除堆栈跟踪重新引发时清除堆栈跟踪在不添加语义value|3363883|Exceptions的情况下更改异常的exception|3363884|Avoid应标记为可疑的Serializable|3363885|When。不要断言，抛出Exception|3363886|Each异常类应该至少有三个原始constructors|3363887|Be在使用AppDomain.UnhandledException+event|3363888|时要小心不要重复发明轮子|3363889|不要使用非结构化错误处理(VB.Net)|3363890|3363891|entityMap|0|LINK|mutability|MUTABLE|url|http://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET^0|8|O|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|29|8|@]|9|@$A|2A|B|2B|1|2C]]|C|$]]|$1|D|3|-4|5|6|7|2D|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|2E|8|@]|9|@]|C|$]]|$1|H|3|I|5|G|7|2F|8|@]|9|@]|C|$]]|$1|J|3|K|5|G|7|2G|8|@]|9|@]|C|$]]|$1|L|3|M|5|G|7|2H|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|2I|8|@]|9|@]|C|$]]|$1|P|3|Q|5|G|7|2J|8|@]|9|@]|C|$]]|$1|R|3|S|5|G|7|2K|8|@]|9|@]|C|$]]|$1|T|3|U|5|G|7|2L|8|@]|9|@]|C|$]]|$1|V|3|-4|5|G|7|2M|8|@]|9|@]|C|$]]|$1|W|3|X|5|6|7|2N|8|@]|9|@]|C|$]]|$1|Y|3|Z|5|G|7|2O|8|@]|9|@]|C|$]]|$1|10|3|11|5|G|7|2P|8|@]|9|@]|C|$]]|$1|12|3|13|5|G|7|2Q|8|@]|9|@]|C|$]]|$1|14|3|15|5|G|7|2R|8|@]|9|@]|C|$]]|$1|16|3|17|5|G|7|2S|8|@]|9|@]|C|$]]|$1|18|3|19|5|G|7|2T|8|@]|9|@]|C|$]]|$1|1A|3|1B|5|G|7|2U|8|@]|9|@]|C|$]]|$1|1C|3|1D|5|6|7|2V|8|@]|9|@]|C|$]]|$1|1E|3|1F|5|G|7|2W|8|@]|9|@]|C|$]]|$1|1G|3|1H|5|G|7|2X|8|@]|9|@]|C|$]]|$1|1I|3|1J|5|6|7|2Y|8|@]|9|@]|C|$]]|$1|1K|3|1L|5|G|7|2Z|8|@]|9|@]|C|$]]|$1|1M|3|1N|5|G|7|30|8|@]|9|@]|C|$]]|$1|1O|3|1P|5|G|7|31|8|@]|9|@]|C|$]]|$1|1Q|3|1R|5|G|7|32|8|@]|9|@]|C|$]]|$1|1S|3|1T|5|G|7|33|8|@]|9|@]|C|$]]|$1|1U|3|1V|5|G|7|34|8|@]|9|@]|C|$]]|$1|1W|3|1X|5|G|7|35|8|@]|9|@]|C|$]]|$1|1Y|3|1Z|5|G|7|36|8|@]|9|@]|C|$]]|$1|20|3|-4|5|6|7|37|8|@]|9|@]|C|$]]|$1|21|3|-4|5|6|7|38|8|@]|9|@]|C|$]]]|22|$23|$5|24|25|26|C|$27|28]]]]

There is an excellent code <a href="http://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET" rel="noreferrer">CodeProject article here</a>. Here are a couple of highlights:

<ul>
<li>Plan for the worst*</li>
<li>Check it early</li>
<li>Don't trust external data</li>
<li>The only reliable devices are: the video, the mouse and keyboard.</li>
<li>Writes can fail, too</li>
<li>Code Safely</li>
<li>Don't throw new Exception()</li>
<li>Don't put important exception information on the Message field</li>
<li>Put a single catch (Exception ex) per thread</li>
<li>Generic Exceptions caught should be published</li>
<li>Log Exception.ToString(); never log only Exception.Message!</li>
<li>Don't catch (Exception) more than once per thread</li>
<li>Don't ever swallow exceptions</li>
<li>Cleanup code should be put in finally blocks</li>
<li>Use "using" everywhere</li>
<li>Don't return special values on error conditions</li>
<li>Don't use exceptions to indicate absence of a resource</li>
<li>Don't use exception handling as means of returning information from a method</li>
<li>Use exceptions for errors that should not be ignored</li>
<li>Don't clear the stack trace when re-throwing an exception</li>
<li>Avoid changing exceptions without adding semantic value</li>
<li>Exceptions should be marked [Serializable]</li>
<li>When in doubt, don't Assert, throw an Exception</li>
<li>Each exception class should have at least the three original constructors</li>
<li>Be careful when using the AppDomain.UnhandledException event</li>
<li>Don't reinvent the wheel</li>
<li>Don't use Unstructured Error Handling (VB.Net)</li>
</ul>

blocks|key|3151070|text|再多一点..。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3151071|您绝对应该有一个集中的异常处理策略。这可以像在try/catch中包装Main()一样简单，失败很快，并向用户显示一条优雅的错误消息。这是“最后的”异常处理程序。|offset|length|style|CODE|3151072|如果可行，先发制人的检查总是正确的，但并非总是完美的。例如，在您检查文件是否存在的代码和您打开它的下一行之间，该文件可能已被删除或某些其他问题可能会阻碍您的访问。在那个世界里，你仍然需要try/catch/finally。根据需要使用抢占式检查和try/catch/finally。|3151073|永远不要“吞下”一个异常，除非在记录最充分的情况下，你绝对、肯定地确定抛出的异常是适合居住的。这种情况几乎永远不会发生。(如果是，请确保只接受特定的异常类--千万不要接受System.Exception。)|3151074|在构建库(供应用程序使用)时，不要吞下异常，也不要害怕让异常冒泡出来。除非你有有用的东西要添加，否则不要重新抛出。永远不要(在C#中)执行以下操作：|3151075|throw+ex;|code-block|syntax|javascript|3151076|因为您将擦除调用堆栈。如果必须重新抛出(这有时是必要的，例如在使用Enterprise+Library的异常处理块时)，请使用以下方法：|3151077|throw;|3151078|归根结底，运行中的应用程序抛出的绝大多数异常都应该在某个地方公开。它们不应该向最终用户公开(因为它们通常包含专有或其他有价值的数据)，而应该通常记录下来，并将异常通知给管理员。为了简单起见，可以向用户呈现一个通用的对话框，可能带有一个参考号。|3151079|.NET中的异常处理与其说是科学，不如说是艺术。每个人都会在这里分享他们最喜欢的东西。这些只是我从第一天开始使用.NET时学到的一些技巧，这些技巧不止一次挽救了我的性命。您的里程可能会有所不同。|3151080|entityMap^0|0|Z|6|0|0|2D|G|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@$D|14|E|15|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|16|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|17|8|@$D|18|E|19|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1A|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|1B|8|@]|9|@]|A|$Q|R]]|$1|S|3|T|5|6|7|1C|8|@]|9|@]|A|$]]|$1|U|3|V|5|P|7|1D|8|@]|9|@]|A|$Q|R]]|$1|W|3|X|5|6|7|1E|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1F|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]]|11|$]]

A few more bits ... 

You absolutely should have a centralized exception handling policy in place. This can be as simple as wrapping <code>Main()</code> in a try/catch, failing fast with a graceful error message to the user. This is the "last resort" exception handler.

Preemptive checks are always correct if feasible, but not always perfect. For example, between the code where you check for a file's existence and the next line where you open it, the file could have been deleted or some other issue may impede your access. You still need try/catch/finally in that world. Use both the preemptive check and the try/catch/finally as appropriate.

Never "swallow" an exception, except in the most well-documented cases when you are absolutely, positively sure that the exception being thrown is livable. This will almost never be the case. (And if it is, make sure you're swallowing only the specific exception class -- don't ever swallow <code>System.Exception</code>.) 

When building libraries (used by your app), do not swallow exceptions, and do not be afraid to let the exceptions bubble up. Do not re-throw unless you have something useful to add. Do not ever (in C#) do this:

<pre><code>throw ex;
</code></pre>

As you will erase the call stack. If you must re-throw (which is occasionally necessary, such as when using the Exception Handling Block of Enterprise Library), use the following:

<pre><code>throw;
</code></pre>

At the end of the day, the very vast majority of exceptions thrown by a running application should be exposed somewhere. They should not be exposed to end users (as they often contain proprietary or otherwise valuable data), but rather usually logged, with administrators notified of the exception. The user can be presented with a generic dialog box, maybe with a reference number, to keep things simple.

Exception handling in .NET is more art than science. Everyone will have their favorites to share here. These are just a few of the tips I've picked up using .NET since day 1, techniques which have saved my bacon on more than one occasion. Your mileage may vary.

blocks|key|3364074|text|下面是我遵循的一些指导原则|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3364075|3364076|Fail-Fast:这更像是一个异常生成准则，对于您做出的每个假设和要进入函数的每个参数，都要进行检查，以确保您从正确的数据开始，并且您所做的假设是正确的。典型的检查包括，参数不为空，在预期范围内的参数等。重新抛出保留堆栈跟踪时的异常-这只是在重新抛出时使用|ordered-list-item|3364077|而不是抛出新的|3364078|()。或者，如果您觉得可以添加更多信息，则将原始异常包装为内部异常。但是如果你捕获一个异常只是为了记录它，那么一定要使用throw；|3364079|不会捕获你无法处理的异常，所以不要担心像OutOfMemoryException这样的事情，因为如果它们发生了，你无论如何都不能做太多事情。|3364080|确实挂起了全局异常处理程序，并确保记录尽可能多的信息。对于winforms钩子，应用程序域和线程未处理异常events.|3364081|Performance只有在您分析了代码并发现它导致了性能瓶颈时才应该考虑，默认情况下会针对可读性和设计进行优化。关于你关于文件存在检查的原始问题，我会说这取决于，如果你能对不存在的文件做些什么，那么就进行检查，否则如果你要做的就是抛出一个异常，如果文件不在那里，那么我看不出有什么意义。，|3364082|，|3364083|，当然有时候需要空的catch块，我认为那些说不是这样的人没有在几个版本中发展的代码库上工作过。但应该对它们进行评论和审查，以确保它们确实是必要的。最典型的例子是开发人员使用try/catch将字符串转换为整数，而不是使用ParseInt().|3364084|If，您希望代码的调用者能够处理错误条件，然后创建自定义异常，详细说明未异常的情况并提供相关信息。否则，就尽可能多地使用内置异常类型。|3364085|3364086|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|12|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|13|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|14|8|@]|9|@]|A|$]]|$1|N|3|O|5|E|7|15|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|16|8|@]|9|@]|A|$]]|$1|R|3|S|5|E|7|17|8|@]|9|@]|A|$]]|$1|T|3|U|5|E|7|18|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|X|$]]

Here are a few guidelines that I follow

<ol>
<li>Fail-Fast: This is more of a exception generating guideline, For every assumption that you make and every parameter that you are getting into a function do a check to make sure that you're starting off with the right data and that the assumptions you're making are correct. Typical checks include, argument not null, argument in expected range etc.</li>
<li>When rethrowing preserve stack trace - This simply translates to using throw when rethrowing instead of throw new Exception(). Alternatively if you feel that you can add more information then wrap the original exception as an inner exception. But if you're catching an exception only to log it then definitely use throw;</li>
<li>Do not catch exceptions that you cannot handle, so don't worry about things like OutOfMemoryException because if they occur you won't be able to do much anyways.</li>
<li>Do hook global exception handlers and make sure to log as much information as possible. For winforms hook both the appdomain and thread unhandled exception events.</li>
<li>Performance should only be taken into consideration when you've analyzed the code and seen that it's causing a performance bottleneck, by default optimize for readability and design. So about your original question on the file existence check, I would say it depends, If you can do something about the file not being there, then yes do that check otherwise if all you're going to do is throw an exception if the file's not there then I don't see the point.</li>
<li>There are definitely times when empty catch blocks are required, I think people who say otherwise have not worked on codebases that have evolved over several releases. But they should be commented and reviewed to make sure that they're really needed. The most typical example is developers using try/catch to convert string to integer instead of using ParseInt().</li>
<li>If you expect the caller of your code to be able to handle error conditions then create custom exceptions that detail what the un excepected situation is and provide relevant information. Otherwise just stick to built-in exception types as much as possible.</li>
</ol>

blocks|key|3151217|text|当重新抛出异常时，关键字自己抛出。这将抛出捕获的异常，并且仍然能够使用堆栈跟踪来查看它来自哪里。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3151218|Try
{
int+a+=+10+/+0;
}
catch(exception+e){
//error+logging
throw;
}|code-block|syntax|javascript|3151219|这样做将导致堆栈跟踪在catch语句中结束。(避免这种情况)|3151220|catch(Exception+e)
//+logging
throw+e;
}|3151221|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

When re-throwing an exception the key word throw by it self. This will throw the caught exception and still will be able to use stack trace to see where it came from.

<pre><code>Try
{
int a = 10 / 0;
}
catch(exception e){
//error logging
throw;
}
</code></pre>

doing this will cause the stack trace to end in the catch statement. (avoid this)

<pre><code>catch(Exception e)
// logging
throw e;
}
</code></pre>

blocks|key|3364202|text|试图坚持的金科玉律是尽可能接近源代码来处理异常。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3364203|如果您必须重新抛出异常，请尝试对其进行添加，重新抛出FileNotFoundException没有太大帮助，但抛出ConfigurationFileNotFoundException将允许捕获该异常并在链上的某个位置对其执行操作。|3364204|我尝试遵循的另一个规则是不使用try/catch作为程序流的一种形式，所以我会验证文件/连接，确保对象已经启动，等等。在使用它们之前。Try/catch应该是针对那些你不能控制的异常。|3364205|至于一个空的catch块，如果你在生成异常的代码中做任何重要的事情，你至少应该重新抛出异常。如果抛出异常的代码没有运行的后果，那么你为什么要首先编写它。|3364206|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|$]]

The golden rule that have tried to stick to is handle the exception as close to the source as possible. 

If you must re-throw an exception try to add to it, re-throwing a FileNotFoundException does not help much but throwing a ConfigurationFileNotFoundException will allow it to be captured and acted upon somewhere up the chain.

Another rule I try to follow is not to use try/catch as a form of program flow, so I do verify files/connections, ensure objects have been initiated, ect.. prior to using them. Try/catch should be for Exceptions, things you can not control.

As for an empty catch block, if you are doing anything of importance in the code that generated the exception you should re-throw the exception at a minimum. If there is no consequences of the code that threw the exception not running why did you write it in the first place.

blocks|key|3151348|text|到目前为止，这里发布的所有建议都是好的，值得注意。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3151349|我想要扩展的一件事是你的问题“与先发制人地测试磁盘上的文件是否存在相比，处理可能抛出的异常是否会对性能造成影响？”|3151350|天真的经验法则是"try/catch块的开销很大“。事实并非如此。尝试并不昂贵。这就是捕获，系统必须创建一个异常对象并用堆栈跟踪加载它，这是很昂贵的。在许多情况下，异常是非常异常的，所以将代码包装在try/catch块中是非常好的。|3151351|例如，如果要填充一个字典，则如下所示：|3151352|try
{
+++dict.Add(key,+value);
}
catch(KeyException)
{
}|code-block|syntax|javascript|3151353|通常比这样做更快：|3151354|if+(!dict.ContainsKey(key))
{
+++dict.Add(key,+value);
}|3151355|对于要添加的每个项，因为只有在添加重复键时才会抛出异常。(LINQ+aggregate查询执行此操作。)|3151356|在您给出的示例中，我几乎不假思索地使用了try/catch。首先，仅仅因为文件在你检查时已经存在并不意味着当你打开它时它就会存在，所以无论如何你都应该处理这个异常。|3151357|其次，我认为更重要的是，除非a)你的进程正在打开数千个文件，b)它试图打开一个不存在的文件的几率并不是很低，否则创建异常对性能的影响是你永远不会注意到的。一般来说，当你的程序试图打开一个文件时，它只会试图打开一个文件。在这种情况下，编写更安全的代码几乎肯定会比编写尽可能快的代码更好。|3151358|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|12|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|14|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|17|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

All of the advice posted here so far is good and worth heeding.

One thing I'd like to expand on is your question "Do handling exceptions which might be thrown have a performance hit compared with pre-emptively testing things like whether a file on disk exists?"

The naive rule of thumb is "try/catch blocks are expensive." That's not actually true. Trying isn't expensive. It's the catching, where the system has to create an Exception object and load it up with the stack trace, that's expensive. There are many cases in which the exception is, well, exceptional enough that it's perfectly fine to wrap the code in a try/catch block.

For instance, if you're populating a Dictionary, this:

<pre><code>try
{
 dict.Add(key, value);
}
catch(KeyException)
{
}
</code></pre>

is often faster than doing this:

<pre><code>if (!dict.ContainsKey(key))
{
 dict.Add(key, value);
}
</code></pre>

for every single item you're adding, because the exception only gets thrown when you are adding a duplicate key. (LINQ aggregate queries do this.)

In the example you gave, I'd use try/catch almost without thinking. First, just because the file exists when you check for it doesn't mean that it's going to exist when you open it, so you should really handle the exception anyway. 

Second, and I think more importantly, unless your a) your process is opening thousands of files and b) the odds of a file it's trying to open not existing are not trivially low, the performance hit of creating the exception is not something you're ever going to notice. Generally speaking, when your program is trying to open a file, it's only trying to open one file. That's a case where writing safer code is almost certainly going to be better than writing the fastest possible code.

blocks|key|3151444|text|在我的经验中，当我知道我要创建异常时，我发现捕捉它们是合适的。例如，当我在web应用程序中执行Response.Redirect时，我知道我将得到一个System.ThreadAbortException。因为它是有意的，所以我只是有一个特定类型的捕获，并将其吞下。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3151445|try
{
/*Doing+stuff+that+may+cause+an+exception*/
Response.Redirect("http:\\www.somewhereelse.com");
}
catch+(ThreadAbortException+tex){/*Ignore*/}
catch+(Exception+ex){/*HandleException*/}|code-block|syntax|javascript|3151446|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

n my experience I've seen fit to catch exceptions when I know I'm going to be creating them. For instances when I'm in a web application and I'm doing a Response.Redirect, I know I'll be getting a System.ThreadAbortException. Since it's intentional I just have a catch for the specific type and just swallow it.

<pre><code>try
{
/*Doing stuff that may cause an exception*/
Response.Redirect("http:\\www.somewhereelse.com");
}
catch (ThreadAbortException tex){/*Ignore*/}
catch (Exception ex){/*HandleException*/}
</code></pre>

blocks|key|360002|text|我非常同意以下规则：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|360003|360004|从不让错误不知不觉地过去。|unordered-list-item|360005|360006|原因是：|360007|360008|当你第一次写下代码时，很可能你不会完全了解第三方代码，.NET+FCL库，或者你的同事最新的贡献。在现实中，你不能拒绝编写代码，直到你很好地了解了每一个异常的可能性。因此，我发现我使用|360009|/|360010|(+exception+ex)只是因为我想保护自己免受未知事物的影响，正如您注意到的，我捕获Exception，而不是更具体的，如OutOfMemoryException等。而且，我总是通过ForceAssert.AlwaysAssert(false，ex.ToString()+);|360011|向我弹出异常(或QA|360012|无论是否定义了DEBUG/TRACE宏，ForceAssert.AlwaysAssert都是我个人的Trace.Assert方式。|360013|开发周期可能是:我注意到了丑陋的断言对话框，或者有人向我抱怨，然后我回到代码中，找出引发异常的原因，并决定如何处理它。|360014|通过这种方式，我可以在很短的时间内写下我的代码，并保护我不受未知领域的影响，但如果发生异常情况，我总是会被发现，这样系统就变得越来越安全。|360015|我知道你们中的许多人不会同意我的观点，因为一个开发人员应该知道他/她的代码的每一个细节，坦率地说，我在过去也是一个纯粹主义者。但现在我了解到，上述政策更加务实。|360016|对于WinForms代码，我总是遵守的一条金科玉律是：|360017|360018|Always+try/catch(Exception)+|360019|始终尝试/捕获(异常)事件处理程序代码|360020|这将保护您的UI始终可用。|360021|对于性能影响，性能损失仅在代码达到catch时发生，执行try代码而不引发实际异常没有显著影响。|360022|异常发生的概率应该很小，否则就不是异常。|360023|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1G|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|1I|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|1K|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1L|8|@]|9|@]|A|$]]|$1|N|3|O|5|E|7|1M|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1N|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1O|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1P|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1R|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1S|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|12|3|13|5|E|7|1U|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|1V|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|1W|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|1X|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|1C|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]]|1D|$]]

I deeply agree the rule of:

<ul>
<li>Never let errors pass unnoticed.</li>
</ul>

The reason is that:

<ul>
<li>When you first write down the code, most likely you won't have the full knowledge of 3-party code, .NET FCL lirary, or your co-workers latest contributions. In reality you cannot refuse to write code until you know every exception possiblity well. So</li>
<li>I constanly find that I use try/catch(Exception ex) just because I want to protected myself from unknown things, and, as you noticed, I catch Exception, not the more specific such as OutOfMemoryException etc. And, I always make the exception being popped up to me(or the QA) by
ForceAssert.AlwaysAssert(false, ex.ToString() );</li>
</ul>

ForceAssert.AlwaysAssert is my personal way of Trace.Assert just regardless of whether the
DEBUG/TRACE macro is defined.

The development cycle maybe: I noticed the ugly Assert dialog or someone else complain to me about it, then I come back to the code and figure out the reason to raise the exception and decide how to process it.

By this way I can write down MY code in a short time and protected me from unknown domain, but always being noticed if the abnormal things happened, by this way the system got safe and more safety.

I know many of you wont agree with me because a developer should known every detail of his/her code, frankly, I'm also a purist in the old days. But nowdays I learned that the above policy is more pragmatic.

For WinForms code, a golden rule I always obey is:

<ul>
<li>Always try/catch(Exception) your event handler code</li>
</ul>

this will protected your UI being always usable.

For performance hit, performance penalty only happens when the code reachs catch, executing try code without the actual exception raised has no significant effect.

Exception should be happened with little chance, otherwise it's not exceptions.

blocks|key|364584|text|请注意，Windows窗体有自己的异常处理机制。如果单击窗体中的某个按钮，并且该按钮的处理程序引发了处理程序中未捕获的异常，则Windows窗体将显示其自己的未处理异常对话框。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364585|要防止显示未处理的异常对话框，并捕获此类异常以便记录和/或提供您自己的错误对话框，您可以在调用Application.ThreadException+()方法中的Application.Run()之前附加到Main事件。|364586|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|$]]

Note that Windows Forms has it own exception handling mechanism. If a button in form is clicked and its handler throws an exception which isn't caught in the handler, Windows Forms will display its own Unhandled Exception Dialog.

To prevent the Unhandled Exception Dialog to be displayed and catch such exceptions for logging and/or for providing your own error dialog you can attach to the Application.ThreadException event before the call to Application.Run() in your Main() method.

blocks|key|364588|text|你必须为用户着想。应用程序崩溃是用户最不希望发生的事件。因此，任何可能失败的操作都应该在ui级有一个try+catch块。没有必要在每个方法中都使用try+catch，但每次用户执行某些操作时，都必须能够处理泛型异常。这并不意味着你可以避免在第一种情况下检查所有东西来防止异常，但是没有没有but的复杂应用程序，操作系统很容易添加意想不到的问题，因此你必须预见到意想不到的情况，并确保如果用户想要使用一个操作，不会因为应用程序崩溃而丢失数据。没有必要让你的应用程序崩溃，如果你捕捉到异常，它永远不会处于不确定的状态，用户总是因为崩溃而感到不便。即使异常位于最顶层，不崩溃也意味着用户可以快速重现异常，或者至少记录错误消息，从而极大地帮助您修复问题。当然比得到一条简单的错误消息，然后只看到windows错误对话框或类似的东西要多得多。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|364589|这就是为什么你永远不能只是自负，认为你的应用程序没有bug，这是不能保证的。而且，将一些try+catch块包装在适当的代码并显示错误消息/记录错误是非常小的工作。|364590|作为一名用户，每当眉毛或办公应用程序或任何东西崩溃时，我肯定会非常生气。如果异常太高，应用程序无法继续，最好显示该消息，并告诉用户要做什么(重新启动、修复某些操作系统设置、报告错误等)。而不是简单地崩溃，仅此而已。|364591|entityMap^0|G|9|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|K|$]]

You have to think about the user. The application crash is the last thing the user wants.
Therefore any operation that can fail should have a try catch block at the ui level.
It's not necessary to use try catch in every method, but every time the user does something it must be able to handle generic exceptions.
That by no means frees you from checking everything to prevent exceptions in the first case, but there is no complex application without bugs and the OS can easily add unexpected problems, therefore you must anticipate the unexpected and make sure if a user wants to use one operation there won't be data loss because the app crashes.
There is no need to ever let your app crash, if you catch exceptions it will never be in an indeterminate state and the user is ALWAYS inconvenienced by a crash.
Even if the exception is at the top most level, not crashing means the user can quickly reproduce the exception or at least record the error message and therefore greatly help you to fix the problem.
Certainly a lot more than getting a simple error message and then seeing only windows error dialog or something like that.

That's why you must NEVER just be conceited and think your app has no bugs, that is not guaranteed.
And it is a very small effort to wrap some try catch blocks about the appropriate code and show an error message / log the error.

As a user, I certainly get seriously pissed whenever a brows or office app or whatever crashes.
If the exception is so high that the app can't continue it's better to display that message and tell the user what to do (restart, fix some os settings, report the bug, etc.) than to simply crash and that's it.

blocks|key|3151579|text|您可以捕获ThreadException事件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3151580|3151581|在解决方案资源管理器中选择一个Windows应用程序项目。|ordered-list-item|3151582|通过双击生成的Program.cs文件将其打开。|3151583|将以下代码行添加到代码文件的顶部：|3151584|3151585|使用System.Threading;|3151586|In+()方法，添加以下内容作为该方法的第一行：|unordered-list-item|3151587|3151588|在ThreadExceptionEventHandler(Application_ThreadException);|3151589|Add+()方法下面添加新的Application.ThreadException+%2B=：|3151590|3151591|static+void+Application_ThreadException(object+sender，ThreadExceptionEventArgs+e)+{+//做日志记录或其他Application.Exit()；}|3151592|在事件处理程序中添加代码来处理未处理的异常。上面的代码将处理应用程序中任何其他地方未处理的任何异常。通常，此代码应记录错误并向用户显示一条消息。|3151593|3151594|参考：https://blogs.msmvps.com/deborahk/global-exception-handler-winforms/|offset|length|3151595|entityMap|0|LINK|mutability|MUTABLE|url|https://blogs.msmvps.com/deborahk/global-exception-handler-winforms/^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|3|1W|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1E|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|1F|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|1G|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1I|8|@]|9|@]|A|$]]|$1|M|3|N|5|O|7|1J|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1L|8|@]|9|@]|A|$]]|$1|S|3|T|5|O|7|1M|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1O|8|@]|9|@]|A|$]]|$1|X|3|Y|5|O|7|1P|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1R|8|@]|9|@$12|1S|13|1T|1|1U]]|A|$]]|$1|14|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]]|15|$16|$5|17|18|19|A|$1A|1B]]]]

you can trap the ThreadException event.

<ol>
<li>Select a Windows Application project in Solution Explorer.</li>
<li>Open the generated Program.cs file by double-clicking on it.</li>
<li>Add the following line of code to the top of the code file:

<pre><code>using System.Threading;
</code></pre></li>
<li>In the Main() method, add the following as the first line of the method:

<pre><code>Application.ThreadException += new ThreadExceptionEventHandler(Application_ThreadException);
</code></pre></li>
<li>Add the following below the Main() method:

<pre><code>static void Application_ThreadException(object sender, ThreadExceptionEventArgs e)
{
 // Do logging or whatever here
 Application.Exit();
}
</code></pre></li>
<li>Add code to handle the unhandled exception within the event handler.
Any exception that is not handled anywhere else in the application is handled by the above code. Most commonly, this code should log the error and display a message to the user.</li>
</ol>

refrence: <a href="https://blogs.msmvps.com/deborahk/global-exception-handler-winforms/" rel="nofollow noreferrer">https://blogs.msmvps.com/deborahk/global-exception-handler-winforms/</a>

I'm currently in the process of writing my first Windows Forms application. I've read a few C# books now so I've got a relatively good understanding of what language features C# has to deal with exceptions. They're all quite theoretical however so what I haven't got yet is a feel for how to translate the basic concepts into a good exception-handling model in my application.

Would anyone like to share any pearls of wisdom on the subject? Post any common mistakes you've seen newbies like myself make, and any general advice on handling exceptions in a way that will my application more stable and robust.

The main things I'm currently trying to work out are: 

<ul>
<li>When should I re-throw an exception?</li>
<li>Should I try to have a central error-handling mechanism of some kind?</li>
<li>Do handling exceptions which might be thrown have a performance hit compared with pre-emptively testing things like whether a file on disk exists?</li>
<li>Should all executable code be enclosed in try-catch-finally blocks?</li>
<li>Are there any times when an empty catch block might be acceptable?</li>
</ul>

All advice gratefully received!

Best Practice for Exception Handling in a Windows Forms Application?

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

我目前正在编写我的第一个Windows窗体应用程序。我现在已经读了一些C#书籍，所以我对C#有哪些语言特性来处理异常有了相对较好的理解。但是，它们都是非常理论的，所以我还没有掌握如何在我的应用程序中将基本概念转换为良好的异常处理模型。有没有人愿意分享一些关于这个主题的智慧珍珠？发布任何你见过的像我这样的新手犯下的常见错...

问Windows窗体应用程序中异常处理的最佳实践？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Windows窗体应用程序中异常处理的最佳实践？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Windows窗体应用程序中异常处理的最佳实践？
EN