Little Awful Practices (II)

This time I'm going to continue with the try-catch examples ;) This thing I found in the code, was also a little stinky. Take a look by yourself:

public static void UpdatePersistentData()
{
 try
 {
  PreferencesManager.UpdatePersistentData();
  TestConfigManager.UpdatePersistentData();
 }
 catch (Exception)
 {
  // ignore
 }
}

Why would someone here want to catch en exception and do nothing with it? Well... this is more common as it should. The reason behind this, I want to believe, is that we don't care if some exception occurs, maybe because it's not crucial for the program's workflow.

Nevertheless I wouldn't agree most of the times with this solution because for me exceptions MUST BE CAUGHT and MUST BE HANDLED.

It happened to me a few months ago to be working on the development of a project which had a dependency for a small library, which was also developed by some guy in the company a few years ago. When the user was under certain environmental conditions the software threw always a crash error, that I had never had. I couldn't debug it, so I start looking deep into my code to try to find where the bug was, but I couldn't really find anything rare. The only suspicious part, was a call to this library, because it was the only part I didn't knew how was working inside. So I reopened that library's project and started looking at the code... and what did I found? Yes, a try-catch section where the catch was actually catching an exception but doing nothing with it!! And this was the reason why my piece of code couldn't detect the true error with a correct message to be shown!

So that's for me the most important reason to catch exceptions: if anything happens (and it'll probably do) your software should notice it to come up with the correct message and you, no matter if you're user or developer, can handle the situation in some way. But at least you can have an idea where does the exception comes from. :)