CODEWITHSUNDEEP
c#exception
Craig Johnston
Craig Johnston

Reputation: 7607

C#: should all exceptions be caught

Should all exceptions be caught in a C# program, or are some exceptions (such as stack overflow, out of memory etc.) ones that you should allow the program to crash on because there is no way to recover from them?

Upvotes: 5

Views: 925

Answers (6)

DrMaxB
DrMaxB

Reputation: 650

When you think that there might be an issue arising from user interaction with your app in an unintended way, then you must always catch a possible exception, and handle it with relevant error messages.

Upvotes: 0

foson
foson

Reputation: 10227

MSDN article on the topic:

http://msdn.microsoft.com/en-us/library/ms229005.aspx

Highlights:

Avoid handling errors by catching non-specific exceptions, such as System.Exception, System.SystemException, and so on, in application code. There are cases when handling errors in applications is acceptable, but such cases are rare.

An application should not handle exceptions that can result in an unexpected or exploitable state. If you cannot predict all possible causes of an exception and ensure that malicious code cannot exploit the resulting application state, you should allow the application to terminate instead of handling the exception. ...

You should catch only those exceptions that you can recover from. ...

Do prefer using an empty throw (throw;) when catching and re-throwing an exception. This is the best way to preserve the exception call stack.

MSDN Magazine on Exception Handling changes in .NET 4.0 - "It's Still Wrong to Use Catch (Exception e)" - http://msdn.microsoft.com/en-us/magazine/dd419661.aspx#id0070057

Upvotes: 1

Sarwar Erfan
Sarwar Erfan

Reputation: 18058

From commercial application development POV, all exceptions should be caught and NONE should be allowed to crash the program. Because, now-a-days, computer users can differentiate between an error message and application crash dialog.

A product that crashes gives bad impression to the customer. When you have no way to recover, you can show an error message politely saying that the app will exit now and the user has to start the app again. Then, gracefully exit when the user presses ok on the modal dialog.

Even sometimes you can give useful information when there is no way to recover. For example, in case of out of memory, you can advise the user to close other applications (if any) before starting this app again.

Though, the end result is same, but a friendly error message gives much better impression than an OS generated crash dialog.

Upvotes: 1

Cameron
Cameron

Reputation: 98886

It depends on the program, of course, but in general, only catch exceptions that you can actually do something about in a meaningful way.

See this question about catching an OutOfMemoryException (you can usually recover from it) and this one about catching a StackOverflowException (generally not possible).

If you're writing a long-running application (e.g. a web server), then of course you'd want to catch all possible exceptions to prevent them from terminating the entire process. If you're writing a low-impact end-user application, then perhaps just logging the exception and failing fast is the best solution.

It's impossible to be (completely) prepared for the unexpected.

Upvotes: 3

bnieland
bnieland

Reputation: 6516

Yes, at the very least exceptions should be logged, giving as much intofmation about the state of the system/program at the time of the crash. The Logging Application Block is one of the more robust automatic ways to log errors.

Upvotes: 1

CampaignWizard
CampaignWizard

Reputation: 838

You should only catch exceptions that you are able to handle. Never ever catch exceptions and do nothing. Do your best to keep the exception from occurring in the first place. This is especially important in .Net because exceptions incur a penalty in performance due to the stack trace.

Upvotes: 7

Related Questions