什么应该是最好的异常处理策略 [英] What should be the best Exception Handling Strategy
问题描述
我工作的应用程序，其中用户调用从UI的方法，在此我呼吁从商务舱的方法，它调用另一个方法
I am working on application where user invokes a method from UI , on this I am calling a method from business class which calls another methods
用户界面 - >方法一 - >方法2 - > Method3
UI--> Method1 -->Method2 --> Method3
我想如果在任何方法发生的任何异常显示错误消息用户
I want to display the error message to user if any exception occurs in any of the method.
要我去直接抛出异常给调用者的方法，并在UI层我将捕获的异常并显示信息。
Shall I go with throwing the exception directly to the caller method and at the UI layer I will catch exception and display the message.
除了在调用者抛出异常和捕获它有没有更好的方式来处理呢？
Apart from Throwing exceptions and catching it at caller is there any better way to handle it?
我不希望使用的地方整数作为结果返回的C ++约定。
I do not want to use the C++ convention where integer is returned as the result.
推荐答案
由于UI的例子 - >方法1 - >方法2 - > Method3，我会确保该UI有一个try / catch，但随后没有其他方法应该捕捉异常，除非他们能够处理它们，无需重新投掷。即使他们处理异常，你应该质疑异常是否应该摆在首位发生。如果你处理异常和去你的快乐的方式，则该异常是这是一个严重的代码味道正常的流程的一部分。
Given your example of UI--> Method1 -->Method2 --> Method3, I would make sure that the UI has a try/catch, but then none of the other methods should catch exceptions unless they can handle them without re-throwing. And even if they handle the exception, you should question whether that exception should happen in the first place. If you handle an exception and go about your merry way, then that exception is part of your normal process flow which is a serious code smell.
下面是我的建议：
1）把你的异常处理代码在所有UI事件，然后有实际的行动养殖至其他方法。不要分散异常处理代码到处都是。它的笨重，使代码难以阅读。
1) Put your exception handling code in all your UI events, and then have the actual action farmed off to some other method. Don't scatter exception handling code all over the place. It's clunky and makes the code hard to read.
protected void Button1_Click(object sender, EventArgs e) {
try {
DoSomething();
}
catch Exception e {
HandleError(e);
}
}
2）不要这样做。你会失去你的堆栈跟踪，谁维护您的代码将追捕你的下一个开发者。
2) Don't do this. You'll lose your stack trace and the next developer who maintains your code will hunt you down.
try {
DoSomething();
}
catch Exception e {
throw e; // don't rethrow!!!
}
如果您不打算来处理异常，别ŧ抓住它。或者，使用裸扔是这样的：
If you aren't going to handle the exception, don't catch it. Or, use a naked throw like this:
try {
DoSomething();
}
catch SomeException e {
HandleException(e);
}
catch {
throw ; // keep my stack trace.
}
3）只能扔在特殊情况下例外。没有try / catch块作为您的正常流程的一部分。
3) Only throw exceptions in exceptional circumstances. Don't have try/catch blocks as part of your normal process flow.
4）如果你要抛出一个异常，不要的过的抛出一个System.Exception的。得出一个异常对象，并把它。我往往只是一个通用的 BusinessException 类。这样一来，你的代码的用户可以决定你做什么异常了，哪些是系统/环境有关。
4) If you're going to throw an exception, don't ever throw a System.Exception. Derive an exception object and throw it. I often just a generic BusinessException class. This way, users of your code can determine what exceptions you made up and which ones are system/environment related.
5）柔道的ArgumentException ， ArgumentNullException 或 ArgumentOutOfRangeException 。如果你发现其中的一个，这是一个编程错误。用户应该不会看到这些异常。
5) Throw ArgumentException, ArgumentNullException, or ArgumentOutOfRangeException if a method caller violates the contract (preconditions) of your method. If you catch one of these, it's a programming bug. A user should never see these exceptions.
如果你还记得的异常应该是一个非常罕见的现象，而且处理它们几乎总是一个UI的关注（所以大头的try / catch语句代码应该留在UI级别），你会做得很好。
If you remember that exceptions should be a very rare occurrence and that handling them is almost always a UI concern (so the bulk of your try/catch code should stay at the UI level) you will do well.
这篇关于什么应该是最好的异常处理策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
