I have a thin client which interacts with the database via a Business class. I am wondering how people with a similar set up have handled in the client code runtime exceptions thrown from the Business class and checked exceptions thrown from the Business class that indicate something serious has gone wrong in the system?
In my Business Layer package I have a BusinessException which is a checked exception. I also have subclasses of this BusinessException for particular problems that can go wrong in one of the business methods - for example RoomAlreadyBookedException.
The idea behind my use of several checked exceptions in my business methods is that the client code that is calling these business methods will be able to identify a particular problem and present the end user with an appropriate, user friendly, error message in a dialog.
So this all works nicely. However, I am a bit worried about what will happen when an runtime exception is thrown from the Business Layer. My client code will just end up outputting the error to the console.
I don't think this is a good approach. All problems that go wrong for the client should notify the user via the GUI I think i.e. with an error dialog.
Serious Checked Exceptions
I am unsure too about what I should actually do with the client when it receives either:
(a) a runtime exception or
(b) an checked exception that indicates something serious has gone wrong.
Should I just notify the user that something has gone wrong and let them continue interacting with a potentially corrupt system? Or should I prompt the user that a problem has occurred and then let them know that the application is closing?
Possibly my thinking is going a bit overboard for the purposes for this assignment? But I would love some opinions\advice from how have you guys handled these scenarios in client code?
I didn't handle runtime exception, because they should simply not occur in a well-developed, well-tested application.
I can't think about any fatal checked exception occuring in the application. The only one which could fit in this category is when the user provides wrong configuration settings and then the user will get a dialog with a user-friendly message and the application simply exits.
Roel De Nijs wrote:I didn't handle runtime exception, because they should simply not occur in a well-developed, well-tested application.
Leaving this assignment aside. I don't think you could approach commercial software like that. There will always be bugs in applications. When they occurr you want your software to behave gracefully. So that is really the reason why I'd like to come up with a good solution now - good to know going forward . I'm sure the markers of this assignment won't care less.
I did a bit of Googling and found setDefaultUncaughtExceptionHandler in the Thread class. Using this will allow you to handle this scenario of exceptions you haven't handled elsewhere (probably because you weren't expecting them). An example of using setDefaultUncaughtExceptionHandler is available on this page here..
It seems like a nice approach. When an unexpected exception bubbles up to the client where you haven't explicitly handled it. You can then log the exception and present the user with some general error message in a dialog. So no nasty stack traces in the command line.
Roel De Nijs wrote:I can't think about any fatal checked exception occuring in the application. The only one which could fit in this category is when the user provides wrong configuration settings and then the user will get a dialog with a user-friendly message and the application simply exits.
The checked exception, RoomNotFoundException, I mentioned on my other thread would be fatal in my eyes. It implies that something serious has gone wrong in the system - some other process has managed to delete a room whilst another process has it locked.
In the application we are developing we have something similar to the setDefaultUncaughtExceptionHandler from the technology/framework (RCP) we are using to develop the application. So I think that's indeed a nice solution, maybe even a bridge too far for this assignment.