blocks|key|156075|text|第二种方法是一个很好的方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|156076|如果您不想通过显示与应用程序无关的运行时异常(即错误)来显示错误和混淆应用程序的用户，那么只需记录错误，技术团队可以查找并解决问题。|156077|try
{
++//do+some+work
}
catch(Exception+exception)
{
+++WriteException2LogFile(exception);//it+will+write+the+or+log+the+error+in+a+text+file
}|code-block|syntax|javascript|156078|我建议您在整个应用程序中采用第二种方法。|156079|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

The second approach is a good one.

If you don't want to show the error and confuse the user of application by showing runtime exception(i.e. error) which is not related to them, then just log error and the technical team can look for the issue and resolve it.

<pre><code>try
{
 //do some work
}
catch(Exception exception)
{
 WriteException2LogFile(exception);//it will write the or log the error in a text file
}
</code></pre>

I recommend that you go for the second approach for your whole application.

blocks|key|156109|text|更好的方法是第二种方法(指定异常类型的方法)。这样做的好处是您知道这种类型的异常可能发生在您的代码中。您正在处理此类型的异常，您可以继续。如果出现了任何其他异常，那么这意味着有些地方出了问题，这将帮助您找到代码中的bug。应用程序最终会崩溃，但您会发现您遗漏了一些需要修复的东西(bug)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|156110|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The better approach is the second one (the one in which you specify the exception type). The advantage of this is that you know that this type of exception can occur in your code. You are handling this type of exception and you can resume. If any other exception came, then that means something is wrong which will help you find bugs in your code. The application will eventually crash, but you will come to know that there is something you missed (bug) which needs to be fixed.

blocks|key|374045|text|对我来说，处理异常可以看作是业务规则。显然，第一种方法是不可接受的。第二种方法更好，如果上下文说明，它可能是100%25正确的方法。现在，例如，您正在开发Outlook外接程序。如果您的插件抛出未处理的异常，outlook用户现在可能知道它，因为outlook不会因为一个插件失败而自毁。你很难弄清楚哪里出了问题。因此，在这种情况下，对我来说，第二种方法是正确的。除了记录异常之外，您还可以决定向用户显示错误消息-我将其视为业务规则。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|374046|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

To me, handling exception can be seen as business rule. Obviously, the first approach is unacceptable. The second one is better one and it might be 100% correct way IF the context says so. Now, for example, you are developing an Outlook Addin. If you addin throws unhandled exception, the outlook user might now know it since the outlook will not destroy itself because of one plugin failed. And you have hard time to figure out what went wrong. Therefore, the second approach in this case, to me, it is a correct one. Beside logging the exception, you might decide to display error message to user - i consider it as a business rule.

blocks|key|374096|text|有例外的情况下，我尝试以下操作：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|374097|首先，我捕获特殊类型的异常，如被零除、IO操作等，并根据这些异常编写代码。例如，除以零，这取决于我可以警告用户的值的出现情况(例如，一个简单的计算器，在中间计算(而不是参数)中得到除以零)，或者静默地处理该异常，记录它并继续处理。|374098|然后，我尝试捕获剩余的异常并记录它们。如果可能，允许执行代码，否则警告用户发生了错误，并要求他们通过邮件发送错误报告。|374099|在代码中，类似于：|374100|try{
++++//Some+code+here
}
catch(DivideByZeroException+dz){
++++AlerUserDivideByZerohappened();
}
catch(Exception+e){
++++treatGeneralException(e);
}
finally{
++++//if+a+IO+operation+here+i+close+the+hanging+handlers+for+example
}|code-block|syntax|javascript|374101|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|6|7|R|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|S|8|@]|9|@]|A|$K|L]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

With Exceptions, I try the following:

First, I catch special types of exceptions like division by zero, IO operations, and so on and write code according to that. For example, a division by zero, depending the provenience of the values I could alert the user (example a simple calculator in that in a middle calculation (not the arguments) arrives in a division by zero) or to silently treat that exception, logging it and continue processing.

Then I try to catch the remaining exceptions and log them. If possible allow the execution of code, otherwise alert the user that a error happened and ask them to mail a error report.

In code, something like this:

<pre><code>try{
 //Some code here
}
catch(DivideByZeroException dz){
 AlerUserDivideByZerohappened();
}
catch(Exception e){
 treatGeneralException(e);
}
finally{
 //if a IO operation here i close the hanging handlers for example
}
</code></pre>

blocks|key|374158|text|唯一应该让用户担心代码中发生的事情的时候，就是他们是否可以或需要做一些事情来避免这个问题。如果他们可以更改表单上的数据，按下按钮或更改应用程序设置以避免该问题，请让他们知道。但是，用户无法避免的警告或错误只会使他们对您的产品失去信心。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|374159|异常和日志是针对开发人员的，而不是针对最终用户的。理解在捕获每个异常时要做的正确事情要比仅仅应用一些黄金法则或依赖于应用程序范围的安全网要好得多。|374160|盲目编码是唯一一种错误的编码。事实上，你觉得在这些情况下可以做一些更好的事情，这表明你投资于良好的编码，但不要试图在这些情况下使用一些通用的规则，并首先理解抛出一些东西的原因，以及你可以做些什么来恢复它。|374161|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|$]]

The only time you should worry your users about something that happened in the code is if there is something they can or need to do to avoid the issue. If they can change data on a form, push a button or change a application setting in order to avoid the issue then let them know. But warnings or errors that the user has no ability to avoid just makes them lose confidence in your product. 

Exceptions and Logs are for you, the developer, not your end user. Understanding the right thing to do when you catch each exception is far better than just applying some golden rule or rely on an application-wide safety net.

Mindless coding is the ONLY kind of wrong coding. The fact that you feel there is something better that can be done in those situations shows that you are invested in good coding, but avoid trying to stamp some generic rule in these situations and understand the reason for something to throw in the first place and what you can do to recover from it.

blocks|key|156288|text|我可以告诉你：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|156289|代码段#1是不可接受的，因为它忽略了异常。(它就像什么都没发生一样吞下了它)。|156290|所以不要添加什么也不做或者只是重新抛出的catch块。|156291|Catch块应该会增加一些值。例如向终端用户输出消息或记录错误。|156292|对于正常的流程程序逻辑，不要使用exception。例如：|156293|例如，输入验证。<-这不是合法的异常情况，应该写IsValid(myInput);方法来检查输入项是否有效。|offset|length|style|CODE|156294|设计代码以避免异常。例如：|156295|int+Parse(string+input);|code-block|syntax|javascript|156296|如果我们传递无法解析为int的值，此方法将抛出和异常，而不是我们可能编写如下代码：|156297|bool+TryParse(string+input,out+int+result);+<-此方法将返回指示解析是否成功的布尔值。|156298|也许这有点超出了这个问题的范围，但我希望这将帮助您在涉及try+{}+catch(){}和异常时做出正确的决定。|156299|entityMap^0|0|0|0|0|0|O|H|0|0|0|0|0|17|0|S|G|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|16|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|17|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|18|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|19|8|@$L|1A|M|1B|N|O]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1C|8|@]|9|@]|A|$]]|$1|R|3|S|5|T|7|1D|8|@]|9|@]|A|$U|V]]|$1|W|3|X|5|6|7|1E|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1F|8|@$L|1G|M|1H|N|O]]|9|@]|A|$]]|$1|10|3|11|5|6|7|1I|8|@$L|1J|M|1K|N|O]]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]]|13|$]]

I can tell you something:

Snippet #1 is not acceptable because it's ignoring exception. (it's swallowing it like nothing happened).

So do not add catch block that do nothing or just rethrows.

Catch block should add some value. For example output message to end user or log error.

Do not use exception for normal flow program logic. For example:

e.g input validation. &lt;- This is not valid exceptional situation, rather you should write method <code>IsValid(myInput);</code> to check whether input item is valid or not.

Design code to avoid exception. For example:

<pre><code>int Parse(string input);
</code></pre>

If we pass value that cannot be parsed to int, this method would throw and exception, instead of that we might write something like this:

<code>bool TryParse(string input,out int result);</code> &lt;- this method would return boolean indicating if parse was successfull.

Maybe this is little bit out of scope of this question, but I hope this will help you to make right decisions when it's about <code>try {} catch(){}</code> and exceptions.

while maintaining my colleague's code from even someone who claims to be a senior developer, I often see the following code:
<pre><code>try
{
 //do something
}
catch
{
 //Do nothing
}
</code></pre>
or sometimes they write logging information to log files like following <code>try catch</code> block
<pre><code>try
{
 //do some work
}
catch(Exception exception)
{
 WriteException2LogFile(exception);
}
</code></pre>
I am just wondering if what they have done is the best practice? It makes me confused because in my thinking users should know what happens with the system.

How using try catch for exception handling is best practice

日志文件

在维护我同事的代码时，我经常看到以下代码：try{  //do something}catch{  //Do nothing}或者有时他们会将日志记录信息写入日志文件，如下面的try catch块try{  //do some work}catch(Exception exception){   WriteExcept...

问如何使用try catch进行异常处理是最佳实践
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何使用try catch进行异常处理是最佳实践EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何使用try catch进行异常处理是最佳实践
EN