NX: exception handling and its justification in choices.txt

[Ulrich Heeger]

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:

catch(IOException io) {
     Data.closeDatabase();
     throw new FatalDBAccessException(io);
}

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:

catch (ControllerException ge) {
         Throwable rootException = ge.getCause();
          if (rootException instanceof FatalSystemException) {
                msg += fatalMessage;
          }
          else { 
                msg += rootException.getMessage();
          }
          ApplicationStarter.handleException(msg);
}

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:

            
catch (StartServerException se) {
         Throwable rootException = se.getCause();
         String msg = "An exception occured while starting the server.\n"
                             + se.getMessage();
 
         if (rootException instanceof IOException 
                 || rootException instanceof RemoteException) {
               msg += "\nThe application will be closed.";
               ApplicationStarter.handleException(msg);
               ApplicationStarter.closeApplication();
          }
          else {
                ApplicationStarter.handleException(msg);
          }
}

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:

 
catch (ControllerException ce) {
        String msg = "Failed to open the connection.\n" 
                             + ce.getMessage();
        Throwable rootException = ce.getCause();
 
         if (rootException instanceof IOException) {
                msg += "\nThe application will be closed.";
                ApplicationStarter.handleException(msg);
                ApplicationStarter.closeApplication();
          }
          else {
                ApplicationStarter.handleException(msg);
          }
}

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:

public RoomAdapter(int accessType, ClientProperties props) 
          throws RemoteException, ConnectionFailsException {
       try{
            ...
       }
       catch (IOException ie) {
            throw new ConnectFailsException(ie);
       }
       catch(MagicCookieException me) {
            throw new ConnectFailsException(me);
       } 
    } 

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 ]

[Philippe Maquet]

Hi Ulrich,

1.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?

Documenting the exception in the javadoc is perfect. And RuntimeExceptions shoudln't be declared in the throws of the methods. So all what you did is perfect IMO.

How can I argue that I anticipate this exception at the business layer without having mentioned it at the DBAccess interface?

As a developer of the business layer, you can anticipate it because you read the javadoc written by the developer of the Data layer... 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.

1.b) Sounds reasonable to me.

1.c) wrap (IMO).

2. What's the RemoteException is for in your local mode?
Now your question: I think that even in local mode, your GUI layer should only know (and care about) the business one. So I prefer your second option (but it's just my opinion).

Best regards,

Phil.

[Ulrich Heeger]

Hi Phil,
nice to hear again from you. I saw that now you are bartender here, congratulations...
I'm really irregulary in this forum, I had a hard time on my job whose contract will fortunately expire end of July. So I haven't also been in Brussels in the meantime, but I will apply for a job in Brussels.
So I can also apply as java developper, if I will finish my assignment one day

But firstly thank you for your help. I will follow your comments and wrap the data layer exceptions in a business level exception.

public RoomAdapter(int accessType, ClientProperties props) 
                                   throws ConnectionFailsException {
        try {
               ...
        }
        catch (RemoteException re) {
             throw ConnectionFailsException(re);
        }
        catch (IOException ie) {
              throw new ConnectionFailsException(ie);
        }
        catch(MagicCookieException me) {
             throw new ConnectionFailsException(me);
        } 
}

But now I have still two questions:
1. If a wrap the IOException, MagicCookieException and RemoteException in a business level exception, how do I get the cause of this new Exception at the GUI layer?
Because I want to handle these exceptions differently at my View class at the GUI layer, like you can see at the code snippet posted in the previous thread:

catch (ControllerException ce) {
                 ...
                if (rootException instanceof IOException)  {
                       msg += "\nThe application will be closed.";
                      ApplicationStarter.handleException(msg);
                      ApplicationStarter.closeApplication();
                }
                else {
                      ApplicationStarter.handleException(msg);
                }
}

Perhaps I should get the cause of the ConnectionFailsException in my Controller class. So I would propagate not wrap the ConnectionFailsException but his cause:

catch (ConnectionFailsException ce) {
             Throwable rootException = ce.getCause();
             throw new ControllerException(rootException);
}

Comments?

2. Concerning Point 2, remote mode of my previous thread:
In order to preserve encapsulation and high abstraction I'm thinking to wrap the IOException and MagicCookieException in the RemoteException. So my constructor of the implementation class of the Remote Connection Factory interface would look like:

   public ConnectionFactoryImpl(String dbPath) throws RemoteException {
            try {
                 ...
            }
            catch (IOException ie) {
      throw new RemoteException(ie);
            }
            catch (MagicCookieException me) {
                 throw new RemoteException(me);
            } 
 }

What do you think about that? Or do I exaggerate the chaining, because the network is not necessarily an architectural layer?


Thanks a lot in advance & greetings to Brussels
Ulrich

[ June 17, 2004: Message edited by: Ulrich Heeger ]
[ June 17, 2004: Message edited by: Ulrich Heeger ]

[Philippe Maquet]

Hi Ulrich,

Sorry to reply so late but I have much work these days and I even expect that it will be worse during the coming week.

1. As your ConnectionFailsException is a sort of "system" exception (in the EJB sense: unrecoverable), why should your GUI layer test for the cause's cause? In your second code exrcept, cannot you simply replace "IOException" by "ConnectionFailsException"? (for all connection failures, whatever the cause, you'll have to close the application, right?).

2. That's what an EJB container does to send any system exception to a remote client, so it cannot be so bad...

Best regards,

Phil.

[Ulrich Heeger]

Hi Phil,
thank you very much for your reply.

1. As your ConnectionFailsException is a sort of "system" exception (in the EJB sense: unrecoverable), why should your GUI layer test for the cause's cause? In your second code exrcept, cannot you simply replace "IOException" by "ConnectionFailsException"? (for all connection failures, whatever the cause, you'll have to close the application, right?).

Yes, you're right, that's what I have done. I have distinguished between the unrecoverable FatalSystemException and the ResourceException allowing a new attempt of the same operation.

2. That's what an EJB container does to send any system exception to a remote client, so it cannot be so bad...

Sounds

Best and thanks a lot again,
Ulrich