Sometimes I do this and I've seen others doing it too:
Try DontWannaCatchIt() Catch End Try
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?
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
Yes, It is possible to have a try block without a catch block by using a final block. As we know, a final block will always execute even there is an exception occurred in a try block, except System.
If any of the code in the try block can throw a checked exception, it has to appear in the throws clause of the method signature. If an unchecked exception is thrown, it's bubbled out of the method. The finally block is always executed, whether an exception is thrown or not.
You cannot skip the execution of the final block. Still if you want to do it forcefully when an exception occurred, the only way is to call the System. exit(0) method, at the end of the catch block which is just before the finally block.
Yes, we can have try without catch block by using finally block. You can use try with finally. As you know finally block always executes even if you have exception or return statement in try block except in case of System.
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.") }
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 (???) { }
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With