FBN :Exception Handling

[Akash Singh]

In my RemoteDataImpl, all methods throw RemoteException.
I am not able to convince myself about exception handling in this class.
for example. i have a three ways to implement exception handling in modify
method, but i do'nt know which one is appropriate. May be, because i do not have much experience.

1.

public void modify(DataInfo newData) throws RemoteException {
     try {
           // dataObject -- is instance of DataAdapter, methods of this  
           // class call method on Data class. modify method throws
           // DatabaseException in Data class,
           // Adapter class rethrows this exception.
           dataObject.modify(newData);
     } catch (DatabaseException dbe) {
         throw new RemoteException("Unable to modify record due to database error",dbe)
     }
}

Comment : How would calling method's user know, whether problem is in DB layer or in RMI layer. For calling method, its ok, it needs to handle this in same way, whether it DatabaseException or RemoteException; inform user about problem and log the stacktrace or whatever. ? IMO, this is not appropriate, because user will get same message, since calling method can not find out directly through exception type real cause, it would display same message(for ex. e.getMessage()) for Remote or Database exception.
2.

public void modify(DataInfo newData) throws RemoteException {
     try {
         dataObject.modify(newData);
     } catch (DatabaseException dbe) {
         throw new RemoteException("Unable to modify record due to database error",dbe)
     } catch (RemoteException re){
         throw new RemoteException("Unable to modify due to network I/O error", re);
     }
}

Comment : This method solves problem which first method has, but it catches
RemoteException, and again create new RemoteException object(performance will go down), just for for adding the message, and wrapping it.
3.

public void modify(DataInfo newData) throws DatabaseException, RemoteException {
        dataObject.modify(newData);     
}

Comment : Calling method can add its message or get the message from thrown object, and display appropriate message for the user, in addition to logging cause. However, problem with this, since calling method has same form of error handling for the exception types except displaying about the problem whether it was database problem or network problem, why should i throw two different exception types.
Which one of these , i should use in my code ?
Regards,
Akash
[ October 26, 2003: Message edited by: Jim Yingst ]

[Dushy Inguva]

Hi Akash,
Its better if you use the third solution. Generally, the design decisions you take while developing a method should not be directed by the method's usage.
What the calling method does with your exceptions is specific to it. You need to throw different exceptions unless you are planning to abstract all exceptions in an application exception (But, this might not apply here)
I thought of giving a more convoluted answer. But later figured this one is just as convoluted
Dushy

[Dushy Inguva]

OUCH !!! Whats with the formatting in this thread ???

[Jim Yingst]

The code blocks included the comments which were really long, with no line breaks. Inside code blocks, the browser won't insert line breaks for you, so that meant that the whole line was really, really, wide, which distorted everythign else on the page. I edited the post to take the comments outside the code blocks.

[Jim Yingst]

I agree, use the third one. You don't need to throw any RemoteExceptions from your code - RMI will do that for you, if & when it's necessary (e.g. if the network connection fails). You need to catch the RemoteExcetpions in whatever code uses these classes, but you don't need to throw them.
Incidentally, the implementation doesn't ever need to say "throws RemoteException". However the remote interface needs to declare thee exceptions, and the generated stub class will throw these eceptions. But the server-side implementation will never, ever throw a RemoteException itselt. That's done by the RMI networking code, which is hidden from us.

[Akash Singh]

Thanks a lot Jim and Dushy. I really appreciate for your response.
Regards,
Akash