Programming Concepts: What should be done when an exception is thrown?

Question

This does not really apply to any language specifically, but if it matters I am using VB.NET in Visual Studio 2008.

I can't seem to find anything really that useful using Google about this topic, but I was wondering what is common practice when an exception is thrown and caught but since it has been thrown the application cannot continue operating.

For example I have exceptions that are thrown by my FileLoader class when a file cannot be found or when a file is deemed corrupt. The exception is only thrown within the class and is not handled really. If the error is detected, then the exception is thrown and whatever function it was thrown in basically quits.

So in the code trying to create that object or call one of its members I use a Try...Catch statement. However, I was wondering, what should even do when this exception is caught? My application needs these files to be intact, and if they are not, the application is almost useless. So far I just pop up a message box telling the user their is an error and to reinstall. What else can I do, or better, what's common practice in these situations?

Answer 1

In your particular situation that's the only way to go.

In another situation... well, it actually depends on the situation.

Answer 2

The common practice is to handle the exceptions you can, and pass on (with optional logging) the ones that you can't. If you hit a problem that just can't be fixed, then no amount of trying again will help and the correct response is to stop.

Answer 3

IMHO there are the following types of exceptions in a system:

1. Recoverable exceptions - these are cases where the system might encounter an exception, but can then default to a state with which it can continue working & show a message to the user that it is can continue with the default option with the user selecting either "Continue", "Retry" or "Cancel" the operation.

2. Non-recoverable exceptions - these are cases where the system has no way to continuing or has any default option. In this case, a user intervention is needed. So the system shows a message to the user with proper guidance of what needs to be done with options to either "Retry" or "Cancel" the operation

Depending on which type of exception you case falls into, I hope this might be useful.

Answer 4

In your case I think just what you're doing - displaying the error to the user with a user-friendly message and then quiting the operation - is exactly what you should do.

I tend to group exception into two categories: Exceptions that you can recover from and exceptions that you can't recover from. Obviously if you can recover from the exception without the user even knowing there was an error, then that's the best option. But in some cases the application just can't move forward and you need to somehow cancel out of the current operation.

Yours doesn't sound like a web app, but if it is, it's often helpful to send an email to the developer when an unexpected error occurs so that the developer can make the appropriate changes.

Also note that a lot of frameworks have a way to catch all uncaught exceptions without enclosing the whole thing in a Try Catch block. For example, ASP.NET 3.5 uses a class called Global.asax that catches all exceptions. Since our application is web based this allows any errors that we didn't expect to get routed through this class and we can send error emails to developers and display the appropriate error page the the user. Although naturally if you expect a possible exception in a certain block of code then you could just put the Try-Catch around that block, but for all others this is helpful.

Answer 5

There are no real general answers to this specific 'problem' but here are some comments that might help you.

• Don't violate your abstractions - If your code is being called at a layer that deals in objects but below uses a SQL data store, it shouldn't let through an SQL exception.

• Don't lose information - Sometimes, people catch exceptions and just ignore them or print a message like "something went wrong". Without sufficient detail (either in the logs or on your screen), you can't identify where/when the problem happened and can spend quite a while debugging.

• Exception hierarchies - This might not apply to all languages but if you can structure your exceptions hierarchically and can catch trees of them rather than just a single one, a lot of code becomes quite clean.

Your approach in your case sounds decent. Inform the user that a fatal error was encountered and abort execution. To borrow from Sunny's excellent answer, it's non-recoverable and so you must request user intervention. Personally, I'd prefer a warning and reverting to a default or something internal if that's possible rather than crashing and asking for a reinstall.

Answer 6

I run into this situation often with internal tools I develop. I usually handle it exactly as you have; show the user an error message, and let them retry or exit.