wood burning stoves*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX:exception handling in Data class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX:exception handling in Data class" Watch "NX:exception handling in Data class" New topic
Author

NX:exception handling in Data class

Robert Huang
Greenhorn

Joined: Dec 15, 2003
Posts: 9
hi,all
In my design, I thougt that all the exception, including all sorts of database operation exception and IOException should be passed to client GUI and handled. But in my DB interface, the exception thrown from method have been definitely restricted, such as:
public String[] read(int recNo) throws RecordNotFoundException;
public void update(int recNo, String[] data, long lockCookie)
throws RecordNotFoundException, SecurityException;
public int[] find(String[] criteria);
public int create(String[] data) throws DuplicateKeyException;
public void unlock(int recNo, long cookie)
throws RecordNotFoundException, SecurityException;
Thus, the methods within my implemented class of DB interface (Data class), has to abide the rule of thrown exception, which are regulated by DB interface.
My question is how I can capture and throw the IOException in methods of Data class? It seems that the only thing which I can do is capturing the IOException and re-throwing a database operation exception(RecordNotFoundException, SecurityException,etc). However,the SUN's requirements has definitely state each database operatio exception should be thrown under different circumstances. For example, in requirement there is a sentence:"Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file."
Especially in find() method, which does not throw any exceptions. All the IO exceptions have to be captuered and handled within this method when calling this method.
Can somebody give me a help clew about what to do?
Thanks in advance!
Robert
Ken Krebs
Ranch Hand

Joined: Nov 27, 2002
Posts: 451
Another alternative is to wrap the IOException in some sort of RunTimeException which does not need to be declared in your throws clause. You can then throw the RunTimeException in your db implementation and then catch and unwrap it in its client.
[ February 10, 2004: Message edited by: Ken Krebs ]

kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Robert Huang
Greenhorn

Joined: Dec 15, 2003
Posts: 9
Thanks, Ken
Yes,it's feasible to solve my baffle. But,would you pls give me an advice that which subclass of RuntimeException I should choose to wrap the IOException. I means there should be a reasonable relationship between the choosed subclass of RuntimeException and IOException.
Thanks again!
Robert
Ken Krebs
Ranch Hand

Joined: Nov 27, 2002
Posts: 451
You could roll your own.
Robert Huang
Greenhorn

Joined: Dec 15, 2003
Posts: 9
hi, Ken
I understand your suggestion is creating my own exception class which extends from RuntimeException instead of using subclass of RuntimeException in JDK. And the IOException should be wraped with this new exception and throw again. Am I right?
Another question need you answer.In my design,I creat the database operation exception according to the SUN's requirements, such as RecordNotFoundException, SecurityException,etc. But, all these exception class extend from DatabaseException, which is another exception class I create for my project. And all sorts of db operation exception will be upcasted as DatabaseException and passed to client GUI. Based on above discussion, another RuntimeException will be used to wraped IOException and passed to client GUI. In client side, only the DatabaseExeption and the specified RuntimeException will be catched.
The reasons why I handle exception as that manner are as follows:
1.I think it can make the execption architecture clear and easy to be handled.
2.Any exception message will not be losted and can be correctly display in GUI, because all the detail error message can be gotten through getMessage(). Thus, there is no necessary to catch all sorts of db operation exception or downcasting the catched DatabaseException in Client side.
Ken, how about your opinion?

Robert
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX:exception handling in Data class