Exiting an application when a runtime error occurs

Question

Hi all,
I have a web applet that allows a users to calculate statistics on weather data in a database, based on some input that the user provides (eg. Date range, geographic region, etc.). Here's what the applet does:
1. Accepts user inputs
2. Pulls appropriate data from the database
3. Calculates stats
4. Returns a chart to the user
What I want to do is gracefully stop execution when an error is found (eg. No data found based on user inputs, can't connect to DB, user input too stringent, etc.). I thought of two ways to do this:
1. Use try/catch blocks everywhere, and propogate them up to the main program, which exits in its own catch.
2. Have some listener monitor for calls to our log4j fatal() method calls, and exit immediately after any fatal() methods are called.
Number 2 would be nice, since once set up, it only requires us appropriately logging in the code.
How do other people deal with this issue of stopping execution when a specific situation arises?
Thanks so much!

Answer 1

gamemusicmaker wrote:
I have a web applet that allows a users to calculate statistics on weather data in a database, based on some input that the user provides (eg. Date range, geographic region, etc.). Here's what the applet does:I assume you mean Java Applet?
What I want to do is gracefully stop execution when an error is found (eg. No data found based on user inputs, can't connect to DB, user input too stringent, etc.). I thought of two ways to do this:You don't really want to stop the execution. You want to tell the user that there is something wrong. And possibly to try again. Or if that's not possible, you display the fatal error message.
1. Use try/catch blocks everywhere, and propogate them up to the main program, which exits in its own catch.Well, you'll have to use try/catch blocks anyways at least for the checked exceptions. Unless you want your program to become really brittle, you do need error handling. Not just "oops, something went wrong. I'll just stop everything instead of providing an error message".
2. Have some listener monitor for calls to our log4j fatal() method calls, and exit immediately after any fatal() methods are called.That seems like a very weird way of handling erroneous situations.