GeeCON Prague 2014*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Where to finally handle remote and database exceptions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Where to finally handle remote and database exceptions" Watch "Where to finally handle remote and database exceptions" New topic
Author

Where to finally handle remote and database exceptions

Melinda White
Greenhorn

Joined: Jun 19, 2002
Posts: 25
Using the Facade pattern to give the client a DataAccess interface object, where should you finally handle the Remote Exception and Database exception (if the current DataAccess interface is a remote object)?
Should the data access facade class catch these exceptions and not rethrow them?

This is my current thinking, but then, my design has changed so many times!
BTW, currently I am registering the dataAccess interface as the remote object, but after reading this site and the sun doc, I will change the object registered to be some kind of factory.
Thanks all in advance for your help and time,
Melinda
P.S. The site referenced above is:
RMI and Factory pattern
Robin Underwood
Ranch Hand

Joined: May 01, 2002
Posts: 117
Since the facade is hiding whether the application is running in local mode or remote mode, the facade should catch RemoteExceptions and rethrow them as higher level application exceptions, such as DatabaseException.
The user needs to know about the higher level exceptions through something like a pop-up message or status area.
Melinda White
Greenhorn

Joined: Jun 19, 2002
Posts: 25
That's a good point about the facade pattern needing to be generic. Thanks for your help.
Melinda
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Melinda,
you might also look here
HTH,
M


Java Regular Expressions
James Du
Ranch Hand

Joined: Mar 23, 2001
Posts: 186
I think the question would come down to how much the user of the Facade would know when some error occurs behind the facade.
If the network error occurs, it's necessary for the client to know its type? my answer is yes, so the user could resort to the administrator. If a database access fails, should the user know whether it happen in the local database or the remote one (put it in another way, should the infomation of local or remote be hided)? my answer is also yes, therefore he/she can determine whether inform the server administrator or check the validation of the database file reside in his/her own pc.
As I understand the principle of what kinds of exception a class should throw, At least the user of the class know what to do in the event of the error.
In my facade, 3 exceptions be thrown:
DatabaseException indicate a local database error occurs
RemoteException indicate a network error occurs
ServerSideException indicate error occurs at the server side
I do not think there's the necessity for the facade to gernelize the RemoteException to a high level Exception.
BTW, I do not agree that DatabaseException is a high level Exception, by contrast, I would rather see it as a low level exception indacating there's something wrong accessing the underlying file.
Robin Underwood
Ranch Hand

Joined: May 01, 2002
Posts: 117
I guess it's a difference of opinion, but I think that what the user cares about is the wording of the message, and what the calling routine cares about is the type of exception.
When the facade rethrows the RemoteException as a higher level exception, it should change the wording to something like "Server is unavailable" for the benefit of the user. Since the facade is hiding whether the client is running in local or remote mode, the client has no use for a RemoteException. It just needs to know that there was some kind of problem accessing the server.
[ July 22, 2002: Message edited by: Robin Underwood ]
James Du
Ranch Hand

Joined: Mar 23, 2001
Posts: 186
When the facade rethrows the RemoteException as a higher level exception, it should change the wording to something like "Server is unavailable" for the benefit of the user.

I cant take your point quite clearly. Do you mean when the facade catch a RemoteException, it rethrow a new RemoteException with the user-friendly message like "Server is unavailable"? or it throw a high level exception, say, FacadeException?
For my case, the calling routine of the facade never extract the message carried with the exception. They analyses the type of the exception, together with its calling context, then pop up a resonable message to the user. Hence, the type of the exception must be transfered up, so the caller is able to know what's going wrong and make the wording of the message as sensible as possible.
Robin, I wonder how your calling routing handled the exception from the facacde? they extract the message of the exception and forward it directly to the user intact?
Regards
James
[ July 23, 2002: Message edited by: James Du ]
Nate Johnson
Ranch Hand

Joined: May 13, 2002
Posts: 301
Originally posted by James Du:

I cant take your point quite clearly. Do you mean when the facade catch a RemoteException, it rethrow a new RemoteException with the user-friendly message like "Server is unavailable"? or it throw a high level exception, say, FacadeException?
For my case, the calling routine of the facade never extract the message carried with the exception. They analyses the type of the exception, together with its calling context, then pop up a resonable message to the user. Hence, the type of the exception must be transfered up, so the caller is able to know what's going wrong and make the wording of the message as sensible as possible.
Robin, I wonder how your calling routing handled the exception from the facacde? they extract the message of the exception and forward it directly to the user intact?
Regards
James
[ July 23, 2002: Message edited by: James Du ]


I am not sure if this is what you are asking, but you can chain exceptions. It is standard in java 1.4 and there are simple articles out there if you are not yet on 1.4 to do the same thing.
Basically, all you do is catch an exception, come up with a nice message for the user as the first arguement to your new excption constuctor, and then pass the exception (the Throwable cause) as the second parameter of the constructor. This appends the stack trace all the way back to the begining of your problem.


scwcd, scjd, scjp<br /><a href="http://natejohnson.us" target="_blank" rel="nofollow">http://natejohnson.us</a><br /><a href="http://rice.kuali.org" target="_blank" rel="nofollow">http://rice.kuali.org</a>
Nate Johnson
Ranch Hand

Joined: May 13, 2002
Posts: 301
Here is a link to an article that I mentioned previously about exception chaining... it tells you how to do it if you are not yet on 1.4
http://developer.java.sun.com/developer/technicalArticles/Programming/exceptions2/
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Originally posted by Nate Johnson:

Basically, all you do is catch an exception, come up with a nice message for the user as the first arguement to your new excption constuctor, and then pass the exception (the Throwable cause) as the second parameter of the constructor. This appends the stack trace all the way back to the begining of your problem.

You also will probably want to call fillInStackTrace() in your overloaded constructor, as it will automatically backfill the exception with all of it's causes in turn. If you handle this right, you'll get extremely deep and detailed exceptions, which you can, in turn, log. That way, your client gets a helpful message, and the (theoretical) system side folks get a rich error message.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
[ July 23, 2002: Message edited by: Max Habibi ]
Melinda White
Greenhorn

Joined: Jun 19, 2002
Posts: 25
thanks everyone for the great links and ideas. This forum is such a great place to learn.
Melinda
 
GeeCON Prague 2014
 
subject: Where to finally handle remote and database exceptions