my dog learned polymorphism*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Propagating exceptions to client Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Propagating exceptions to client" Watch "Propagating exceptions to client" New topic
Author

Propagating exceptions to client

David Winters Junior
Ranch Hand

Joined: Oct 30, 2007
Posts: 47
All,

Im stuck on a particular issue here regarding how can i propagate exceptions back to the client. This isssue is caused as a result of the limitations provided by the interface provided by Sun.

Here is one of the methodfs provided by Sun in the provided interface:
public void update(int recNo, String[] data) throws RecordNotFoundException

Now in this method i would need to be able to throw an iOException back to the the caller method which in turn will rethrow this exception back to the client etc etc.

The issue is that we i try to catch an IOException in the caller method here i get a compilation error related to the catxh block being unreachable which makes sense as the update method does not declare it in its declartion which im not allowed to do.

To workaround this issue i catch a generic java.lang.Exception and rethrow so that if the update method above throws an IOException we will catch it and rethrow it.

Are there any other means of working around this compilation issue due to the exception decalartion restriction here in the declared interface so that i can catch the actual IOException type here and rethrow it back to the client?

BTW, i know for certain exceptions i can sublass the RuntimeException class and retrow these types of exceptions without declaring them in the specified method defintion.

Thanks for your thoughts.
David
Herman Schelti
Ranch Hand

Joined: Jul 17, 2006
Posts: 387
hi David,

two things:

-why do you want the client to catch an IOException, if the update method will never throw it?

-personally, I don't think the client should know how the server stores the data.

I made an exception class to wrap the actual exception:
-it extends runtime exception, so you don't have to declare or catch it.
-if the server would start using a database, you don't have to change the client

succes,Herman
David Winters Junior
Ranch Hand

Joined: Oct 30, 2007
Posts: 47
Herman,

the update method in the implementation could possibly throw an IOException since it accesses the file system at some point so i think yes what i can do here catch the IOException in the catch block as you suggested and throw a custom exception which is a subclass of the RuntimeException class and throw it as it doesnt need to be declared.


Thanks.
David
Adrian Engler
Greenhorn

Joined: Sep 18, 2006
Posts: 29
Originally posted by David Winters Junior:
All,

Im stuck on a particular issue here regarding how can i propagate exceptions back to the client. This isssue is caused as a result of the limitations provided by the interface provided by Sun.

Here is one of the methodfs provided by Sun in the provided interface:
public void update(int recNo, String[] data) throws RecordNotFoundException

David


I would say there are basically three options:
- catching checked exceptions and throwing unchecked exceptions (extending RuntimeException) for them
- using another interface than the one provided by Sun as the one that is exposed to the client (I don't know whether this is different in other versions of the specification, but in my version, it was only required that the interface provided by Sun was implemented, but it didn't have to be the one exposed to the client) - in that case, any exceptions including checked exceptions can be declared, of course. However, since the interface provided by Sun still has to be implemented, this would hardly lead to a clean and simple solution.
- using checked exceptions that extend the checked exceptions declared in the interface provided by Sun (such as RecordNotFoundException); in most cases, this is probably not a good solutions (unless the exception really means that a record has not been found).

The best solution in that case is probably to wrap checked exceptions in exceptions that extend RuntimeException.

In the client, I would not catch java.lang.Exception, but only the exceptions that can really be thrown by the client (both the checked exceptions like RecordNotFoundException declared in the interface provided by Sun and additional unchecked exceptions).

Adrian


SCJP 5.0 (93%), SCWCD (98%), SCJD (377/400), SCBCD (100%)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Propagating exceptions to client
 
Similar Threads
NX: URLy Bird 1.3.1 Explicit Fatal Exception Handling
Exception Handling behaviour
IOException in db find method
checked exceptions
NX: About data consistent