Error handling

[Nate Johnson]

Just wondering what people were doing for user messages. Are you just giving a simplified message to the user in a message box? What about stack traces? I was thinking it might be useful to have a button that would also display the stack trace to the user so that they could pass that on to a potential help desk. Maybe this is just overkill.

[Max Habibi]

Hi Nate,
This is an excellent question, and one that deserves serious thought. There are several stragies you might consider: a few follow.
1) you can have loggers server side that log all errors: this could be three seperate loggers(network, gui, db), or a single large logger. Advantages: it's a very elegent solution. Disadvatages: the logging might break down, thus introducing a point of failure for your application.
2) you can simply log every message to the display, thus creating a running system analysis. Advantages: it's useful information, though not quite as elegent as the above. Disadvantages: it can be messy in displaying: after all, too much information is no information.
3) you can swallow errors. advantage: very easy to do. disadvantages: might fail the exam.

All of these, of course, are for servers side error handling. client side, you almost certainly want to catch the error and display a friendly message to the user: ex: "the server could not be contact at address localhost. Please confirm that it is functioning".
My suggestion is to create your own custom error objects, throw them as neccessary, catch them gui side, and display a friendly message if you do so.
HTH,
M
The Sun Certified Java Developer Exam with J2SE 1.4

[Gosling Gong]

About the exception in Client side, there are following options,
1) throw all the specific Exceptions all the way to the client GUI, in the GUI, just
catch(Exception e) { showMessage(e.getMessage()...}
2) throw all the specific Exceptions only in the Data interface implementation, but catch all the Exceptions in a Data service layer(or Facade), and re-throw a new DataException with friendly message.
3) similiar to the above, but make DatabaseException extends ChainedException
4) create client specific Exceptions such as FlightBookException, throw them in the data service layer(facade)
The idea that throw different exception at different layers is excellent, but I can not come up with a perfect implementation.

as to 2) 3), there will be such kind of code with every method in the Data Facade class
try {
} catch(RemoteException e) {
throw new DatabaseException("Remote Data Service Access Error");
} catch(IOException e) {
throw new DatabaseException("Remote Database Access Error");
} finally {
}
by the way, should I also catch the DatabaseException and the rethrow it with a new message like "Database Access Error"?
furthermore, do you think I should also include the messages generated by the caught Exceptions, like throw new DatabaseException("Remote Data Service Access Error:" + e.getMessage());
as to 4), I don't think it's necessary to have a new Client specific Exception class, because the exceptions used in client are only used to show a error message to the user, then, why bothering create new classes?
what are your opinions?