Unnecessary try / catch block
-
Whilre reviewing the code from some contract developers, I have found a common construct:
public void SomeMethod() { try { // some code here... } catch (Exception exception) { throw exception; // Just re-throw } }Why just catch and re-throw an exception? This just adds to the complexity of the execution without doing anything in return. -
Whilre reviewing the code from some contract developers, I have found a common construct:
public void SomeMethod() { try { // some code here... } catch (Exception exception) { throw exception; // Just re-throw } }Why just catch and re-throw an exception? This just adds to the complexity of the execution without doing anything in return.I would wrap that in an
# if DEBUG; too many times when debugging I can't figure out where an exception happened, especially when there's afinallyinvolved. -
I would wrap that in an
# if DEBUG; too many times when debugging I can't figure out where an exception happened, especially when there's afinallyinvolved.Yep it can be useful for debugging. Anyway, I'd use just
throw;to rethrow exception, as that way I don't lose stack trace IIRC.
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus
-
I would wrap that in an
# if DEBUG; too many times when debugging I can't figure out where an exception happened, especially when there's afinallyinvolved. -
Whilre reviewing the code from some contract developers, I have found a common construct:
public void SomeMethod() { try { // some code here... } catch (Exception exception) { throw exception; // Just re-throw } }Why just catch and re-throw an exception? This just adds to the complexity of the execution without doing anything in return.I once worked with a programmer who wrote code like that. He yelled at me (in front of the big boss) for getting rid of it. It turns out he wasn't aware that .Net puts a stack trace in Exception objects! The real lesson that *I* learned is "old habits die hard"; he was still using techniques from back in the C++ / COM days.
-
I would wrap that in an
# if DEBUG; too many times when debugging I can't figure out where an exception happened, especially when there's afinallyinvolved.I agree with the use of conditional statements for this purpose, but they are not there and this is supposedly debugged code. I can also see re-throwing if there is a finally block cleaning up, regardless of the use of conditionals. What I didn't show was that there are typically three or four lines of code inside the try block...
-
I once worked with a programmer who wrote code like that. He yelled at me (in front of the big boss) for getting rid of it. It turns out he wasn't aware that .Net puts a stack trace in Exception objects! The real lesson that *I* learned is "old habits die hard"; he was still using techniques from back in the C++ / COM days.
I feel you pain. Old habits do die hard, so the trick is learning the right habbits. Asking yourself "Do we have a backup?" is the best habbit to have. Beyond that is a functional understanding of what the compiler is doing to your source, regardless of the language. Unfortunately too many people try to compare a medium-level language like C or C++ to a high level language like C# based on the syntactical similarities alone.
-
Whilre reviewing the code from some contract developers, I have found a common construct:
public void SomeMethod() { try { // some code here... } catch (Exception exception) { throw exception; // Just re-throw } }Why just catch and re-throw an exception? This just adds to the complexity of the execution without doing anything in return.Actually, this code has a somewhat subtle behavior, since it is catching by-value, prior to throwing. If a derived exception is thrown, it will be "clipped" to the base class when it is thrown. This could be potentially different from invoking throw, which would throw the derived class.