I'm close to start working with networking and GUI of my application and started to wonder, what is the desired way of GUI handling and throwing exceptions?
I mean, I've got 3 layer application, and I was thinking that if the record is not found - I could use the RecordNotFoundException which is thrown from the URLyBird service class (which is bubbled from the underlying Data class which really throws it).
Should the RecordNotFoundException be thrown in the GUI, or perhaps BusinessException should be thrown instead with description saying what's wrong?
Then again, I would like to inform user that the room he wants to book has already been booked by another user, so I can:
- Create new exception like RoomAlreadyBookedException (which will be thrown only from service layer, and cought only by GUI layer)
- Use BusinessException - mentioned above - and set appropriate message.
As I like the main idea of Business Exceptions, I don't really like the idea of putting reasons in the exception message. It's OK if I want to show the user very generic information what happened in a form of alert window with message of exception as it's content. But what if I would like to present user a different error window, for example a YES/NO dialog - I would end up with matching exception message strings to see if it is the right communicate or not. This idea feels like a VERY bad idea.
So if I end with creating new BLL/GUI Exceptions (like RoomAlreadyBookedException) what about RecordNotFoundException. Should I reuse the one from Data class, or to be strict, should define something like RoomNotFoundException in BLL/GUI which would wrap the RecordNotFoundException?
What should be the desired design?
Also, did you inform user that there was a problem with initializing record's cache (during some storage media exception)?
If yes, than what the user could do in this situation?
In my business layer I catch the exceptions from the database layer, and throw specific business exceptions instead. In the controller (in my client) all these business exceptions are caught and wrapped in a GUIException with an appropriate (and understandable) message for the user. And this message is shown in an error dialog to the user.
If there is a problem during server startup (in networked mode) or the client application (in networked mode or standalone mode) the user is informed by an appropriate message (depending on the error: server does not exist, database file is invalid, ...) and the application finally exits.