1

When handling exceptions for example in a method in my presentation logic, is it ok to catch all possible exceptions in a one catch block as follows if the only purpose here is alerting the user.

private void Do()
{
    try
    {
        //  Do some stuff here which might throw an exception
    }
    catch (Exception e)
    {
        MessageBox.Show(e.Message);
    }
}

Or else should we always catch every possible exceptions (like OutOfMemoryException, NullReferenceException etc. followed by more generalized exceptions) in separate catch blocks ?

Since the information in e.message is not relevant for average users, we could do like

MessageBox.Show("Exception occurred and contact system administrator");

Is that the standard way ?

NOTE : My sole purpose is to alert user and try to keep the system up (with out crashing)

2

IMHO if that is ok depends mostly on the context of the Do method, and what you know about the stuff in the try-block. Lets assume you have an UI application, and the Do part is just a Button-Click handler. Lets further assume the part within the try block does some fairly complex non-UI things which might fail with any kind of unforseeable exception (but normally it should not, and when it does, there has happened something severe). So if your failure handling strategy is to display the exception message to the user and let him or her decide what to do next (for example, he can decide to close and restart the application, or to ignore the error), then catching all type of exceptions is just the way to go. That might not be a perfect solution, but it is pragmatic and works for a lot of real world cases.

Of course, you should make sure the user has enough information to make the correct decision. A general message like "an Exception occurred" is typically not enough information. So think about what you can present to your users and what not. If you fear your typical user cannot understand the failure message, show him the "general message", but make sure the support people or admin can get the real message afterwards (maybe from a log file, maybe from a separate menu entry etc.) If you use something like a log file, logging the stack trace of the exception maybe also a good idea, since it will help you (the developer) to find the root cause in case of an internal program error.

However, if you know that the part within the try block can sometimes throw an exception which makes it impossible for your program to proceed (like an OutOfMemoryException, or maybe an exception which indicates that a severe internal program error has occurred, or something like that), you should catch that individually, show the reason of failure to the user and end the program afterwards automatically. Think about what the most user-friendly behaviour is. Does it make sense to let the user decide if the program should proceed, or is there a chance if the user ignores the error, that he will loose or destroy parts of his data now? If the latter is the case, better not let the user decide - better end the program in a controlled manner.

The former was just an example - the gist is: think about the responsibilities for failure handling: what is in your case the responsibility of the user, what is the responsibility of the UI part (the button handler), and what is the responsibility of the part in the try block - then you can make a decision of which exceptions to catch and which information to display.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.