删除过多的try-catch块 [英] Removing excessive try-catch blocks

问题描述

我正在重构由其他开发人员编写的中等大小的WinForms应用程序，几乎每个类的每个方法都被一个 try-catch 块包围。 99％的时间这些catch块只记录例外或清理资源并返回错误状态。

我认为很明显，这个应用程序缺乏正确的异常处理机制， '计划删除大多数try-catch块。

这样做有什么缺点吗？你会怎么做的？我打算：

• 要正确记录异常情况并阻止他们传播给用户，请使用 Application.ThreadException 处理程序




• 对于需要清理的资源的情况，请将try-catch块保留为

更新：使用使用或 try-finally 块是一个更好的方法。感谢您的回复。

• 在返回false-on-error的方法中，让异常传播并在调用者中捕获而是

欢迎任何更正/建议。

编辑在第三个项目中，使用return-false-on-error我的意思是这样的方式：

  bool MethodThatDoesSomething（）{
 try {
 DoSomething（）; //可能抛出IOException 
} catch（异常e）{
 return false; 
} 
} 
  

我想将其重写为： p>

  void MethodThatDoesSomething（）{
 DoSomething（）; //可能抛出IOException 
} 
 
 // try-catch在调用者中，而不是检查MethodThatDoesSomething的返回值
 try {
 MethodThatDoesSomething（）
} catch（IOException e）{
 HandleException（e）; 
} 
  

解决方案

防止他们传播给用户，有一个Application.ThreadException处理程序

你能告诉用户发生了什么吗？所有例外都会结束吗？

对于需要清理的资源的情况，请将try-catch块视为

如果您希望在其他地方处理异常，您也可以使用 try-finally 块。还要考虑使用在 IDisposable 资源中使用关键字。

在返回false-on-error的方法中，让异常传播并在调用者中捕获它，而不是

这取决于方法。异常只能在特殊情况下发生。一个 FileNotFoundException 对于 FileExists（）方法来说是怪异的，但完全合法的被抛出 OpenFile（）。

I'm refactoring a medium-sized WinForms application written by other developers and almost every method of every class is surrounded by a try-catch block. 99% of the time these catch blocks only log exceptions or cleanup resources and return error status.

I think it is obvious that this application lacks proper exception-handling mechanism and I'm planning to remove most try-catch blocks.

Is there any downside of doing so? How would you do this? I'm planning to:

• To log exceptions appropriately and prevent them from propagating to the user, have an Application.ThreadException handler

• For cases where there's a resource that needs cleanup, leave the try-catch block as it is

Update: Using using or try-finally blocks is a better way. Thanks for the responses.

• In methods that "return-false-on-error", let the exception propagate and catch it in the caller instead

Any corrections/suggestions are welcome.

Edit: In the 3rd item, with "return-false-on-error" I meant methods like this:

bool MethodThatDoesSomething() {
    try {
       DoSomething(); // might throw IOException
    } catch(Exception e) {
       return false;
    }
}

I'd like to rewrite this as:

void MethodThatDoesSomething() {
   DoSomething(); // might throw IOException
}

// try-catch in the caller instead of checking MethodThatDoesSomething's return value
try {
   MethodThatDoesSomething()
} catch(IOException e) {
   HandleException(e);
}

解决方案

"To log exceptions appropriately and prevent them from propagating to the user, have an Application.ThreadException handler"

Would you then be able to tell the user what happened? Would all exceptions end up there?

"For cases where there's a resource that needs cleanup, leave the try-catch block as it is"

You can use try-finally blocks as well if you wish to let the exception be handled elsewhere. Also consider using the using keyword on IDisposable resources.

"In methods that "return-false-on-error", let the exception propagate and catch it in the caller instead"

It depends on the method. Exceptions should occur only in exceptional situations. A FileNotFoundException is just weird for the FileExists() method to throw, but perfectly legal to be thrown by OpenFile().

这篇关于删除过多的try-catch块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！