Why is it "bad" to only have an exception catch block?

[The Fire Snake]

I know with exceptions that many times you want to catch specific types and do different actions depending on which one occurs. For example, if there is an IndexoutofBounds exception you might want to log and continue the app but if you have a Network exception of some type you might want to log and stop the app. But here is my question. Often times I need to take the same exact action no matter what type of exception occurs. Mostly with my apps, I log the exception and redirect to an error page. Therefore I usually have just one exception catch block, so that it catches all types of exceptions and does the same actions. I have read/heard many say that is bad. Why is it bad? What is my alternative? I couldn't possibly list out every type of exception type in catch blocks and repeat the same actions in each block? That is insane.

Could someone give me their advise? Thanks.

[GBeats]

Hi

its fine in certain circumstances and for a personal app

but there are times when you may need to distinguish say from an error that will effect other parts of your program to errors that may only effect a certain operation your performing.
example, you may try an operation will gets half way through and corrupts the data, obviously you dont want to just stop the operation and go back to where you was, you need to check the data, reload it, start fresh etc where as if it gets an error at a point where no data has been modified, then its ok to go back a step, maybe fix the error with code so the user can try again.

as for a public application, its essential so you can know(through public feedback) and then modify your code and fix all the problems.

[jmcilhinney]

First of all, you should only ever be writing Catch blocks for exceptions that you know for a fact can reasonably be thrown. You don't just stick Catch blocks in just in case something might happen. You think about what can happen and then you you write code accordingly. If an exception can reasonably be avoided then, in most cases, you should avoid it, e.g. test for Nothing before using a reference if it might be Nothing.

If you're writing a Catch block for the base Exception type then it generally means that you haven't actually thought about what might go wrong. It generally just means that you've decided that something might go wrong without considering what that is specifically. You say that you need to do the same thing for all exceptions but how can you possibly know that if you don't know what all the exceptions might be? You might have considered one specific circumstance that might cause an exception to be thrown or even two or three but, if you catch Exception then you will be catching exceptions that you haven't even considered and, therefore, have no idea about the origin or cause of. If you have no idea what caused an exception then how can you possibly know how to proceed after it's thrown? If you know that one or more specific exceptions can be thrown in a particular place then you write Catch blocks for those one or more specific exceptions and you clean up and proceed as appropriate for those exceptions.

Any exceptions that you haven't anticipated leave your app in an unknown state and, therefore, the only genuinely safe course of action is to exit. You should have a global exception handler in all your apps, which means handling the UnhandledException event of the application in VB WinForms, and there you should log the exception and exit. If the client really wants to be able to keep working then you can give them that option but you should make it crystal clear to them that they do so at their own risk.

[Evil_Giraffe]

Mostly with my apps, I log the exception and redirect to an error page.

That sounds like a "something went wrong, I don't know what, let's just gracefully exit" type of response, which is exactly what the global exception handler jmc referred to is for. I don't really think of this as "catching the exception" nor "handling the error", and perhaps others who suggest not to catch Exception don't either, hence the confusion?

[ident]

Catching System.Exception is swallowing it and claiming we can handle it.

Handling unhandled exceptions part 1

Vexing exceptions

Application.UnhandledException Event

[jmcilhinney]

Any exceptions that you haven't anticipated leave your app in an unknown state and, therefore, the only genuinely safe course of action is to exit. You should have a global exception handler in all your apps, which means handling the UnhandledException event of the application in VB WinForms, and there you should log the exception and exit. If the client really wants to be able to keep working then you can give them that option but you should make it crystal clear to them that they do so at their own risk.

Here's how we manage unhandled exceptions in one particular app:

Private Sub MyApplication_UnhandledException(ByVal sender As Object, ByVal e As UnhandledExceptionEventArgs) Handles Me.UnhandledException
    Using dialogue As New frmUnhandledException(e.Exception) With {.StartPosition = FormStartPosition.CenterParent}
        Select Case dialogue.ShowDialog()
            Case DialogResult.Retry
                'Restart
                e.ExitApplication = False
                Windows.Forms.Application.Restart()
            Case DialogResult.Abort
                'Exit
                e.ExitApplication = True
            Case DialogResult.Ignore
                'Continue
                e.ExitApplication = False
        End Select
    End Using
End Sub

[Grimfort]

If you have no idea what caused an exception then how can you possibly know how to proceed after it's thrown?

Why would you not be able to decide how to proceed?

My app processes requests from multiple sources, any individual source can be (and should be) removed from the system to ensure others continue. This is part of the design of the app, so generic handlers exist on all entry points that can be recovered from (IP stacks, timer events). On a different app (or in fact, in my UI), generic exceptions would put the app into an unknown state and should be avoided, some cases I can continue, others I cannot, each should be checked on a case-by-case basis.

I am a very defensive coder, everything is checked for the correct type and existence before it is used to limit the exceptions being raised in the first place. The generic exceptions are the last resort for those things that are unexpected and allow me to bail at a high level, gracefully, the specific exceptions are to allow continuation as I should know that I might get it, and know how to continue.

Some might say that actually, my generic handling is known handling as I do actually do something as a result of the exception, so is it really an unknown exception?
There are even cases where you might need a generic catch and really NOT do anything, ie, logging to a database, don't care what type of exception happens, could be network, could be bad data, could be database space, anything. Whatever the problem is, the failure within that block is just logging and should have no impact on the next part of the process.

Personally, I think it is bad to use a generic catch unless you have understood why you are adding one, which is why it gets negative press. It seems to me that you have investigated the need, understood the use and are using it for a valid purpose.

[Grimfort]

Here's how we manage unhandled exceptions in one particular app

That's exactly how my UI works as well. I think they have complicated things however with ThreadException, FormsUnhandled and AppDomain.Unhandled ...

[Evil_Giraffe]

Why would you not be able to decide how to proceed?

My app processes requests from multiple sources, any individual source can be (and should be) removed from the system to ensure others continue.

And what if the exception was due to something going wrong in the hosting app?

This is part of the design of the app, so generic handlers exist on all entry points that can be recovered from (IP stacks, timer events).

A better design, IMO, that actually let you do this safely would be to load a new AppDomain for each of these "sources". Assign a global error handler to each of the child AppDomains that will signal to the hosting process that the source has gone bad and tear down that AppDomain gracefully.

There are even cases where you might need a generic catch and really NOT do anything, ie, logging to a database, don't care what type of exception happens, could be network, could be bad data, could be database space, anything. Whatever the problem is, the failure within that block is just logging and should have no impact on the next part of the process.

Simply logging should not swallow the exception. If you catch Exception for this purpose (and I'm not entirely sure that's a good idea, but let's go with it for now), you should throw the exception from the handler block to let the exception bubble further up. Logging that an error occurred is not "handling" the exception.

[Grimfort]

And what if the exception was due to something going wrong in the hosting app?

I didn't want to bloat the post, any time the hosting apps data is being accessed, individual message queues are used that can each in turn be thrown away. If its a process exception (outofmemory for example), its snookered anyway. (On the side, seen the 4.5 changes to process exceptions?)

A better design, IMO, that actually let you do this safely would be to load a new AppDomain for each of these "sources". Assign a global error handler to each of the child AppDomains that will signal to the hosting process that the source has gone bad and tear down that AppDomain gracefully.

Possibly, each source can be an IP connection, a database, email, SNMP others etc. I've never had a need to investigate AppDomains as currently "it works ".

Simply logging should not swallow the exception. If you catch Exception for this purpose (and I'm not entirely sure that's a good idea, but let's go with it for now), you should throw the exception from the handler block to let the exception bubble further up. Logging that an error occurred is not "handling" the exception.

Possibly my post was confusing. The ignorable exception I suggested, could be the logging of a message that was itself was an exception, for example IO failure as out of disk space is caught, and you want to write this information to your database, which also fails as it is on the same machine.

The main point of my post, is that I think it is viable to use generic catches, as long as you use them correctly.

[ident]

Catching the correct handlers cleanly identifies the exception and also shows you are expecting them and you know how to deal with them. If catching Exception & claiming we can handle it is a good idea then what would be consider a good handler for exceptions like StackOverflowException. If i need an Event to be raised while multi threading i would catch exception and send it back to the UI.