• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

exceptions handling

 
Andrew Douglas
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi people!
Could you tell me if this is good way to handle exceptions?
public int xxx() throws DatabaseException {
try {
return 5;
} catch (Exception e) {
if (e instanceof RemoteException )
throw new DatabaseException("Remote ivocation error: " + e.getMessage());
else if (e instanceof DatabaseException)
throw new DatabaseException("Database error: " + e.getMessage());
else throw new DatabaseException("Unknown error: " + e.getMessage());
}
}
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you plan to catch Exception, then you will end up consuming programmatic errors. ie runtime errors which c'd be as a result of a mistake in the coding logic.
This looks like client code since you are
expecting a RemoteException.
I think RemoteException exists to signal that something has gone wrong with the network connection.
Why do you want to wrap it in a DatabaseException which indicates something else?
Having separate catch clauses makes the error handling code much more readable.
If you want the client to handle a single type of exception, why not create another ClientException class and wrap the database exceptions / remote exception in it / rather just send a message to the client as to what message it must display?
 
Andrew Douglas
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for reply.
I will explain in more details what I mean.
------------------------------------------
On server side I have an interface:
interface CommonInterface {
int xxx() throws Exception;
}
public class RemoteClass implements CommonInterface, Remote {
public int xxx() throws RemoteException, DatabaseException {
return data.getXXX();
}
}
-------------------------------------
On the client side I have business logic tier:
public int xxx() throws ClientException {
try {
CommonInterface ci = (CommonInterface)Naming.lookup("RemoteClass");
//******Here I have to catch Exception.
ci.xxx();
//******Do you mean create ClientException
//******and handle exception like:
} catch (RemoteException re) {
throw new ClientException("Remote Error");
} catch (DatabaseException de) {
throw new ClientException("Database Error");
} catch (Exception e) {
throw new ClientException("Unexpected Error");
}
Thank you. Andrew.
 
Colin Froggatt
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,
I have just been looking at the same aspect of the client. I too have a common interface that is impl'ed for a Local data object and a remote data object.
Because the spec's say's "should include a class that implements the same public methods as the suncertify.db.Data class" I don't want that interface to throw RemoteException - this means that the RMI stuff is transparent to the client code.
I have decided to subclass DatabaseException. This means that any method that currently throws DatabaseException (most) can also throw DatabaseCommunicationException (dbe). I still have to add dbe to some methods that don't throw exceptions in the first place, but thats easier to justify.
What do you other guy's think? Did you throw RemoteExceptions from the client Data interface or did you all convert the RemoteEx like we are suggesting?
Cheers, BigC
 
Andrew Douglas
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Colin,
I have read two discussions on this topic.
http://www.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=25&t=001084
http://www.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=25&t=000418
But I have a problem. Do I have to catch Runtime Exceptions (e.g. NullPointerException) and show message to user? For example "There are some problems in processing your request."
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Andrew Douglas:
Do I have to catch Runtime Exceptions (e.g. NullPointerException) and show message to user? For example "There are some problems in processing your request."

Null pointer definitely indicates that something is wrong with the code.
If the client has to necessarily enter some data, that needs to be verfied by expilicitly checking for nulls and if so he needs to be informed.
Don't catch NullPointerException for the same.
As i have already suggested, it might occur because of coding errors and that might go unnoticed and hence a Bug.
As for my design,
Yeah i remember having relayed a common ClientException to the client with a message.
The layer between the client and the actual classes which handle read(), modify()
decide what needs to be done if an exception occurs.
If they decide not to do anything, an exception is thrown back to the GUI layer indication the same. in my case i just sent back a decent message.
ahh the only case in which I remeber having done something is when i caught the RemoteException.
I assumed that remote exception might occur due to network issues. So i had code which re-attempted the same..
try{
doFunc();
}catch(RemoteException re){
Thread.sleep(1000);
try{
doFunc();
}catch(RemoteException e){
throw new ClientException("Could'nt do it");
}
}
am not so sure if you guys would like it though.
But i thought we s'd make atleast one more attempt in case of remot eexception before aborting.
 
Andrew Douglas
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Karthik.
I almost finished my assignement. But exceptions handling and documentation are the last topics I am worried about.
I have one more question.
So, if there are some errors in logic of the code it is a BUG.
In this case is it necessary to show to user message that there is somethig wrong.
Thank you in advance. Andrew.
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Andrew Douglas:
So, if there are some errors in logic of the code it is a BUG.
In this case is it necessary to show to user message that there is somethig wrong.

ok this is what i meant..
void method(String name){
try{
...
s = name.substring(1,name.indexOf('a'));
remoteIns.remoteMethod();
}catch(RemoteException e){

}catch(Exception e){
throw new CLient...("some message");
}
now if indexOf returns -1, then substring throws an exception i guess (stringIndexoutof.)
But it's quite possible that you might want to do something else if this happens.
So you c'd've checked that -1 is getting returned from string.indexOf() operation.
Worst case yes you might again throw an exception(ClientException).
But you w'dve been in a position to throw a more specific message.
In your case, Exception clause will catch it and throw the same message irrespective of what the runtime exception is.
We cannot write buggy code. I mean a bug surfaces only when it is unearthed.
But we can't write code thinking that there will always be some flaw :-)! which turns out to be the case anyway :-)
So,
By catching the base exception (java.lang.Exception) and throwing a generic message indicating failure, we are eliminating the chances of finding possible flaws in the code.
rather s'd i say we are covering up our flaws.
Or atleast print / log the stack trace before throwing the exception so that you will be aware of what is happening in there.
Hope am clear Or probably someone else can give a better explanation.
 
Colin Froggatt
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,
But I have a problem. Do I have to catch Runtime Exceptions (e.g. NullPointerException) and show message to user?

I would say that you do have to catch ALL exceptions at some point and then, as karthik says, display a message to the user (and probably log a stack trace - users don;t need to see this). It would not be acceptable to allow an Exception to bubble up and out of the app as that would terminate the app - crash == unhappy user
However, I would have that catch as close to the client as possible. I general, if you don't know what to do with an Exception, propagate it up the call stack to allow another part of the program to deal with it. If no one deals with it, then it will bubble out and go Bang!!
I seem to be working in the reverse direction to most people. I have done all the serverside stuff first and now I'm getting ot my client so I havn't actually done this exception trapping yet.
Hope this helps. BigC
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic