Lance's Whiteboard

Random scribbling about C#, Javascript, Web Development, Architecture, and anything else that pops into my mind.

News


Creative Commons License
Lance's Whiteboard Blog by Lance Hunt is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
Based on a work at weblogs.asp.net



Sponsored Ad
Sponsored Ad

Blogs I Read

Try/Catch annoyances

The Try/Catch block is the source of many of my pet peeves, here is one of my favorite petty annoyances:

Eating Exceptions:

try
{
  … do something meaningful
}
catch(SomeException ex)
{
   // eat exception
}

This is an example of a block that is intended to eat exceptions (for the sake of argument, lets assume there is a valid reason).

[remark: i'll save my lecture on the pitfalls and evil of eating exceptions for another day]

I see this in many projects.  In and of itself the code isn’t bad, depending upon its usage. I just dislike seeing the “ex” variable hanging out there.  The variable name is redundant and generates the warning The variable 'ex' is declared but never used.”  Instead, just omit the variable name, and keep the exception type filter like this:

 
try
{
  … do something meaningful
}
catch(SomeException)
{
   // eat exception
}

 
More than anything else, what bothers me is the REASON why the “ex” variable was left-in.  Usually, developers leave it so they can see the exception when stepping-through code in the VisualStudio debugger.   

 I wonder if the following should be done:

 A)      Make the Visual Studio debugger treat catch blocks differently and always step "onto" that line and give you a smart tag with the exception instance being caught/eaten.

B)      Add a new keyword to C# (and other languages) to make “eating” exceptions more explicit.  Ex:   try/eat or try/catch/eat instead of try/catch

[update: pruned this post to avoid conveying the sentiment that eating exceptions is a good thing (thanks to Paul for making me smack myself upside the head)]
Posted: Jan 15 2007, 05:16 PM by CodeSniper | with 6 comment(s)
Filed under:

Comments

Wim Hollebrandse said:

Obviously the other annoyance that springs to mind and that I'd expect you to mention when I was reading your post is a rethrow of the caught exception like:

try

{

 // whatever...

 // several lines of code

}

catch (Exception ex)

{

 // some logging

 throw ex;

}

Which destroys the original stack trace of where the exception originated in the first place.

Instead, either simply use "throw;" or wrap the exception with your own exception class and attach the original exception as an inner exception in the appropriate overloaded exception constructor.

# January 15, 2007 7:07 PM

Gabriel Lozano-Moran said:

'Eating' exceptions is one of the bad practices and the day that Microsoft decides to add this to the C# language specifications I will walk over to J2EE. Bug hiding is never, but truly never a good idea.

# January 16, 2007 12:10 AM

Uwe said:

I _never_ silently eat exceptions. The least thing I _always_ do is to log exceptions.

# January 16, 2007 12:31 AM

John said:

So you don't like "ex" hanging out there (when you can name it whatever you like) but instead want extra, unnecessary syntax? did you know you can have multiple catches each with a different type of exception?

# January 16, 2007 9:53 AM

CodeSniper said:

Wim - Agreed.  Except the "throw ex" is more than just a pet-peave, its down right evil!

Paul - I agree that eating exceptions should not be encouraged.  Perhaps the "eat" keyword idea goes a bit too far.  

Wilco - I agree that the unused exception declaration shouldnt be neccessary, and developers should seek other ways, but it is still quite a common practice.  The quest is, how do we help the developer to do the right thing?  Education is fine, but it would be nice to take it one step further.

Uwe - That is the policy everyone should follow.  Basically, stick to the "Dont catch an exception unless you can handle it."

John - My point wasnt about the "ex" variable name, it was about the fact there is any variable name at all, when the exception isnt referenced.   Yes, I'm aware of exception filters, but I'm not sure how that applies here.  All that really means is that you might have several instances of unreferenced declarations - which is exactly what I'm trying to discourage.

# January 16, 2007 10:19 AM

CodeSniper said:

Perhaps a simpler solution would be to have the compiler issue a warning on any block that results in eaten exceptions.  Then, for those of us with "Treat Warnings as errors" enabled, we can enforce review of this code before any release.   Otherwise, the "The variable 'ex' is declared but never used." warning might be overlooked and the eaten exception go undetected.

# January 16, 2007 10:32 AM

Wim Hollebrandse said:

Lance - I don't think swallowing exceptions is less evil than "throw ex;"...

I would say they're at least on a par in terms of 'evilness'!

# January 16, 2007 1:02 PM