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)]