Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Removing excessive try-catch blocks

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);
}
like image 574
henginy Avatar asked Aug 10 '11 08:08

henginy


People also ask

How do I stop multiple try catch blocks?

To avoid writing multiple try catch async await in a function, a better option is to create a function to wrap each try catch. The first result of the promise returns an array where the first element is the data and the second element is an error. And if there's an error, then the data is null and the error is defined.

What happens if there are several catch blocks?

The superclass exception cannot caught first. The superclass exception must be caught first. Either super or subclass can be caught first.


1 Answers

"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().

like image 92
C.Evenhuis Avatar answered Sep 17 '22 13:09

C.Evenhuis