Are Try Catches still useful?

Question

When I first started programming in .NET I used try/catches all the time. I am finding lately though I rarely ever use them for web applications. My exception (no pun intentended) is unmanaged code that could potentially create a memory leak such as com objects. Are they really needed anymore or do they just clutter things up?

UPDATE: Assume custom errors are being used to take care of the ugly stack trace page.

Answer 1

I find that junior programmers use try/catch WAY too heavily. The decision to use try/catch should boil down to these simple rules:

• can you handle the error? (perhaps this means to try again, or use different settings, return substitute values, etc)

• can you provide a better error message (more detail) ?

• do you need to log this specific error? (keep in mind that all errors should be logged at the highest level -- for example in the global.asax file in Application_Error method)

• do you need to clean up/dispose resource used within an operation, such as a database connection or transaction?

If you answered yes to any of these, then sure, use try/catch. If you said no, then you can safely just allow an error page to be displayed and have the global error handler log it.

If you do intend to log or clean up resources, but still let the exception pass through, make sure you use throw; and not create a brand new exception. Doing so will eliminate your stack trace and basically give the error no context.

Just found this excellent quote from Ayende that seems to put it very nicely:

Exception handling should appear in exactly two places:

• When an error is expected (making a web request call, for example) and there is some meaningful behavior to be done in the case of a failure (such as retrying after some delay)
• On a system boundary, in which case you need to make a decision about how you are going to expose the error to the outside world.

Answer 2

Here's the answer in the form of a question

How do you expect to do error handling if you don't catch exceptions?

Exceptions (rightly or wrongly) are the error mechanism of the .Net language. You simply cannot write an application which both ignores exceptions and has sufficient error handling. It's ingrained into the framework and cannot be avoided

Answer 3

Try catches are an important aspect of programing and should not be ignored; however you don't need to have every statement wrapped in a try catch block. Generally I use the following rules:

1. If this is a windows application, then the entry point should always have a try catch as a last ditch attempt to catch any exceptions. In asp.net this is done using the OnError of the Application objects.

2. If I know that a specific exception can be thrown and I want to handle it. For example if you try and send an email with an invalid format for the send to email address you'll get a format exception. I might catch that specific exception and notify the user that the email they are using is not valid.

3. If you have additional contextual information that you want to log that would be useful for troubleshooting. For example, while my global asp.net error handler might log all the form variables, perhaps I want to capture values of certain objects.

4. If you want to modify the flow of the application, for example in ASP.Net if I want to display an error message when my ajax call fails, I shouldn't let the error bubble to my unhandled exception routine.

5. If there are resources which need to be cleaned up, then I use a try catch finally, or a try finally block to ensure my resources are closed up.