In my tenure as a software engineer, I've seen a lot of poorly written code, especially in my C++ days. Pointer magic that had no business being compiled, and error handling that was slim to non-existent. Even in the world of .NET, it's still possibly to write dangerous code:
try
{
// Call a method may throw an exception
}
catch ( Exception ex )
{
// Eat the exception
System.Diagnostics.Debug.WriteLine( ex.Message );
}
How many times have you seen code like that? Hell, sometimes I don't even see the Debug.WriteLine. Sometimes they just eat the exception. Exceptions aren't a bad thing. In fact, having an exception occur is a good thing. I still remember something my advisor said during a class talking about pointers at MSOE... "If you're lucky, it will blow up."
The worst errors that can occur are the ones that don't have outward signs. Perhaps you did some bad pointer arithmetic, but instead of throwing an exception because you illegally accessed memory, it simply reads that memory and a counter equals 50 instead of 5. Your program could appear to function perfectly, but will provide incorrect results. Worse yet, when an symptom does finally appear... the symptom will so far away from the cause, that you may never find it.
Eating exceptions is about the closest you can come in .NET without trying really hard. People are so afraid of seeing a box with that red X, that they eat them left and right without realizing that having an immediately failure that is easy to identify and fix is preferable to a bug that is impossible to track down.
Exceptions happen for a reason... and that reason should be taken seriously. If you can write code to handle that exception in a catch block, then by all means do it. But if your "exception handling" code simply boils down to logging it and continuing... do yourself a favor and rethrow that exception (or don't catch it at all) and put your program out of its' misery. You'll thank me in the long run.