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.