Why can't I write just a try with no catch or finally? [closed]

Question

Sometimes I do this and I've seen others doing it too:

VB:

Try     DontWannaCatchIt() Catch End Try 

C#:

try  {      DontWannaCatchIt(); }  catch {} 

I know I should catch every important exception that I'm expecting and do something about it, but sometimes it's not important to - or am I doing something wrong?

Is this usage of the try block incorrect, and the requirement of at least one catch or finally block an indication of it?

Update:

Now I understand the reason for this, and it's that I should at least comment on the empty catch block so others understand why it's empty. I should also catch only the exceptions I'm expecting.

Luckily for me I'm coding in VB so I can write it in just one catch:

Catch ex As Exception When TypeOf ex Is IOException _                     OrElse TypeOf ex Is ArgumentException _                     OrElse TypeOf ex Is NotSupportedException _                     OrElse TypeOf ex Is SecurityException _                     OrElse TypeOf ex Is UnauthorizedAccessException     'I don't actually care. End Try 

Answer 1

If you don't want to catch it, why are you using try in the first place?

A try statement means that you believe something can go wrong, and the catch says that you can adequately handle that which goes wrong.

So in your estimation:

try {     //Something that can go wrong } catch {     //An empty catch means I can handle whatever goes wrong. If a meteorite hits the     //datacenter, I can handle it. } 

That catch swallows any exceptions that happen. Are you that confident in your code that you can handle anything that goes wrong gracefully?

The best thing to do (for both yours and your maintenance programmer's sanity) is to explicitly state that which you can handle gracefully:

try {     //Something that could throw MeteoriteHitDatacenterException } catch (MeteoriteHitDatacenterException ex) {     //Please log when you're just catching something. Especially if the catch statement has side effects. Trust me.     ErrorLog.Log(ex, "Just logging so that I have something to check later on if this happens.")  } 

Answer 2

No, you should not catch every important exception. It is okay to catch and ignore exceptions you don't care about, like an I/O error if there's nothing you can do to correct it and you don't want to bother reporting it to the user.

But you need to let exceptions like StackOverflowException and OutOfMemoryException propagate. Or, more commonly, NullReferenceException. These exceptions are typically errors that you did not anticipate, cannot recover from, should not recover from, and should not be suppressed.

If you want to ignore an exception then it is good to explicitly write an empty catch block in the code for that particular exception. This makes it clear exactly what exceptions you're ignoring. Ignoring exceptions very correctly is an opt-in procedure, not an opt-out one. Having an "ignore all exceptions" feature which can then be overridden to not ignore specific types would be a very bad language feature.

How do you know what types of exceptions are important and should not be caught? What if there are exceptions you don't know about? How do you know you won't end up suppressing important errors you're not familiar with?

try { } // I don't care about exceptions. catch { } // Okay, well, except for system errors like out of memory or stack overflow. // I need to let those propagate. catch (SystemException exception) {     // Unless this is an I/O exception, which I don't care about.     if (exception is IOException)     {         // Ignore.     }     else     {         throw;     } } // Or lock recursion exceptions, whatever those are... Probably shouldn't hide those. catch (LockRecursionException exception) {     throw; } // Or, uh, what else? What am I missing? catch (???) { }