C #: should all exceptions be thrown

Question

Should all exceptions get into the program in C # or some exceptions (for example, a stack overflow, from memory, etc.) that you must allow the program to crash because there is no way to restore them?

Answer 1

You should only catch exceptions that you can handle. It never catches exceptions and does nothing. Make every effort to ensure that the exception occurs first. This is especially important in .NET because exceptions carry a performance penalty due to stack tracing.

Answer 2

Of course, it depends on the program, but, in general, only catch exceptions that you can really do something in a meaningful way.

See this question about detecting OutOfMemoryException (usually you can recover it) and this fooobar.com/questions/64409 / ... (usually not possible).

If you are writing a multi-year application (for example, a web server), then, of course, you will want to catch all possible exceptions so that they do not stop the whole process. If you are writing an application with a low level of impact for the end user, then perhaps just logging the exception and fast crash is the best solution.

It is impossible to be fully prepared for the unexpected.

Answer 3

Yes, at least, exceptions should be logged, providing the same amount of information about the state of the system / program during a crash. The protocol logging unit is one of the most reliable automatic methods for recording errors.

Answer 4

Related MSDN Article:

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

Main characteristics:

Avoid error handling by catching non-specific exceptions like System.Exception, System.SystemException, etc. in the application code. There are times when error handling in applications is acceptable, but such cases are rare.

An application should not handle exceptions that could lead to an unexpected or accessible state. If you cannot predict all the possible causes of the exception and make sure that the malicious code cannot use the resulting state of the application, you must allow the application to stop working instead of handling the exception. ...

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

Do prefer to use an empty throw ( throw; ) when catching and throwing an exception. This is the best way to keep an exception call stack.

MSDN Journal of Exception Processing Changes in .NET 4.0 - “It Still Does Not Fit to Use Catch (Exception e)” - http://msdn.microsoft.com/en-us/magazine/dd419661.aspx#id0070057

Answer 5

From the development of commercial POV applications, all exceptions must be caught, and NONE must be allowed to crash the program. Because currently, computer users can distinguish between an error message and an application crash dialog.

A product that fails gives a bad impression to the customer. When you have no way to recover, you can display an error message, politely declaring that the application will exit now, and the user must restart the application. Then, gracefully exit when the user clicks ok in the modal dialog box.

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

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

Answer 6

If you think that a problem may arise due to unintentional user interaction with your application, you should always catch a possible exception and handle it with appropriate error messages.

Answer 7

Its always good practice to catch all the exceptions. otherwise, he could display a yellow screen of death.

When you know the possible exceptions, use a few catch blocks and write them down accordingly. If not, use the more general Exception class and register an exception message so that you can take this action later.