Hi everyone,
I'm working on my choices.txt before uploading hopefully my assignment this week. Ouff ...
It seems to me that I have big difficulties to get a structure for the justification of my exception handling.
So I would be very glad if you could help me concerning two points:
1. For IOException and InterruptedException within Data.class, I wrap these exceptions in an instance of a subclass of the RuntimeException, called FatalDBAccessException. Let's see a code-snippet:
a) Of course, I include this exception in the javadoc throws-tag in Data. Should I also include it in the throws-tags of the DBAccess and RemoteDBAccess interface?
I haven't included them until now, but I'm wondering if I should do that. Because, at the business logic level, I wrap the unchecked FatalDBAccessException in an unchecked FatalSystemException. How can I argue that I anticipate this exception at the business layer without having mentioned it at the DBAccess interface?
(The reason why I chain the FatalDBAccessException with an unchecked exception, the FatalSystemException, consists in the presumption that no recovery action can be done by the client).
b) Like we can see at the code-snippet, I will catch the IOException to close the access to the database because I don't know if a corruption of the datas occured.
No further database access will be possible for any client because each access is handled through one random access file stream which has been closed now.
At the GUI layer the Controller Class wraps the FatalSystemException in a checked ControllerException and my View class handles this exception like following:
whereby the fatalMessage should include something like: "A serious message occured at the system level. Please close the application. For more detailed informations see the log messages or consult the administrator."
What do you think about that strategy?
c) Generally it's better to catch low-level exceptions and to wrap these in higher-level exceptions to be rethrown.
Like mentioned above FatalDBAccessExceptions are caught to be wrapped in a business FatalSystemException. In my application I have the business layer implemented at the client side. So my business methods might throw a RemoteException. What do you think about that? Should I propagate the remote exception back to the GUI client or wrap them also in a FatalSystemException?
2. In the precedent point, I described how I handle the IOException within my Data class. Here I will point out how I handle the IOException and the MagicCookieException which may occur at the start of the application when the connection to the database happens:
When I start the RMI-Server or the application in standalone mode, there is the moment where I pass the path of the database file to a singleton instance of my so-called MetaData class. This singleton will read the Schema Description section of the database while it's instantiation. Here an IOException or a MagicCookieException might occur. I will show how I handle these exceptions for the two different modes.
remote mode: Here the business logic layer won't be taken in consideration, because the Server GUI invokes a method belonging to the network layer, the called startServer of my RoomServer class. This method creates the remote object to register and to rebind. Each exception will be wrapped there in a so-called StartServerException to be thrown to the Server-GUI, so also the IOException and MagicCookieException. At the Server-GUI I have following catch-clause:
I decided to close the application if a remote exception occurs since the unbinding and rebinding procedure as recovery action is a little bit complicate and beyond the requirements of this assignment. I will close the application also when an IOException occurs because I don't know if this exception results of a false database path or if the data in the database is corrupted, so I shut down the application.
local mode: In this case, the IOException and MagicCookieException are propagated up to the constructor of the Controller Class at my User-Interface. Here they will be wrapped by the GUIControllerException. The client's Configuration-GUI would catch this exception before starting the main window: In this case I close the application too, if an IOException occurs.
a) I think that's appropriate also for the local mode to propagate the IOException up to the client layer: If I want to set up the connection to the database it's important to know the reason why it fails. And I could make an easy distinction between the failure due to an IOException and for example MagicCookieException.
A second option could include the wrapping of the IOException and MagiCookieException in a business level exception, perhaps called ConnectionFailsException.
So the constructor of my RoomAdapter class would look like:
But then it would be a little more complicate for the GUI layer to handle differently a connection failure due to an IOException or a MagicCookieException.
What do you think about that?
I hope that I haven't confused you with this long
thread, but I would be very glad, if you could help me.
Thanks a lot in advance & lot of greetings
Ulrich
[ June 16, 2004: Message edited by: Ulrich Heeger ]
[ June 16, 2004: Message edited by: Ulrich Heeger ]
BTW, and if you didn't yet, you could add a paragraph about the FatalDBAccessException in the javadoc general section of your Data class. Doing so will increase the chances that a user of your Data class will care about your @throws tags.
