Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

URLyBird : DB Interface & Exceptions: Please HELP!

 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
I have the following problem: none of the methods in the interface throws IOException. So, if any exception occurs while communication with file I have NO way to deliver this exception to the client. Currently I use user-defined RuntimeException, but it is not good...

Some people beleive we can just change interface, but I do not, because there is the software which will test our server doesn't expect interface method to throw IOException.
How did you solve this problem???
Thanx a lot in advance,
Vlad
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad,
Depending on your version of the instructions, you should find that most of the methods do throw some form of exception - quite often RecordNotFoundException. So you could catch the IOException and throw the RecordNotFoundException with the reason taken from the IOException. If you are using JDK 1.4 (and I think you need to be) then you can even chain the exceptions.
Alternatively, it is quite possible that RuntimeException may be a valid exception to throw in this case. After all, if you get an IOException, what is the user code going to do with it?
Regards, Andrew
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alternatively, it is quite possible that RuntimeException may be a valid exception to throw in this case. After all, if you get an IOException, what is the user code going to do with it?
I favor this strategy. An IOException isn't a RecordNotFoundException (which sounds like "I looked and the record wasn't there") - it's more like "your DB is probably hosed for some reason, and you really should exit, restart, and hope things are better then." And since not all methods can throw RecordNotFoundException, or any checked exception in some cases (find()) you can't deal consistently with the problem using checked exceptions. It's better if all the methods throw a RuntimeException in this case, IMO - at least it's consistent.
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
First of all thanks for your reply.
I considered the idea to pack IOException into RecordNotFoundException. DB interface has find() method, which does not throw any exception So it is not a solution.
What you said about Runtime exception that is what I am using now. I will say that the User can't do anything about it so it is RuntimeException, but it is very arguable.
Can anybody explain what does it mean Exception chaining in jdk 1.4??? You can chain Exceptions in jdk 131 either (by re-throwing it!?)
Regards,
Vlad
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad,
Can anybody explain what does it mean Exception chaining in jdk 1.4??? You can chain Exceptions in jdk 131 either (by re-throwing it!?)

Re-throwing exceptions is not the same as chaining exceptions. When you re-throw an exception, you may loose information about what the initial cause was - all you can do is set a message which will hopefully make sense when it finally gets to the class that will handle the exception.
With a nested exception, the exception that you throw contains the exception that you caught. So when it gets printed in a stack trace it would appear as:

Looking at this, I can see both the high level exception with it's error message and the lower level exception with it's error message.
This is all enabled by some changes to the Throwable class. The API explains this better than I can, so from the Sun API for throwable:

(A throwable) can contain a cause: another throwable that caused this throwable to get thrown. The cause facility is new in release 1.4. It is also known as the chained exception facility, as the cause can, itself, have a cause, and so on, leading to a "chain" of exceptions, each caused by another.
One reason that a throwable may have a cause is that the class that throws it is built atop a lower layered abstraction, and an operation on the upper layer fails due to a failure in the lower layer. It would be bad design to let the throwable thrown by the lower layer propagate outward, as it is generally unrelated to the abstraction provided by the upper layer. Further, doing so would tie the API of the upper layer to the details of its implementation, assuming the lower layer's exception was a checked exception. Throwing a "wrapped exception" (i.e., an exception containing a cause) allows the upper layer to communicate the details of the failure to its caller without incurring either of these shortcomings. It preserves the flexibility to change the implementation of the upper layer without changing its API (in particular, the set of exceptions thrown by its methods).
A second reason that a throwable may have a cause is that the method that throws it must conform to a general-purpose interface that does not permit the method to throw the cause directly. For example, suppose a persistent collection conforms to the Collection interface, and that its persistence is implemented atop java.io. Suppose the internals of the put method can throw an IOException. The implementation can communicate the details of the IOException to its caller while conforming to the Collection interface by wrapping the IOException in an appropriate unchecked exception. (The specification for the persistent collection should indicate that it is capable of throwing such exceptions.)
A cause can be associated with a throwable in two ways: via a constructor that takes the cause as an argument, or via the initCause(Throwable) method. New throwable classes that wish to allow causes to be associated with them should provide constructors that take a cause and delegate (perhaps indirectly) to one of the Throwable constructors that takes a cause. For example:


Because the initCause method is public, it allows a cause to be associated with any throwable, even a "legacy throwable" whose implementation predates the addition of the exception chaining mechanism to Throwable. For example:


Does this explain it for you?
Regards, Andrew
[ July 08, 2003: Message edited by: Andrew Monkhouse ]
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,
Tnanx for your reply,
I have read also some articles yesterday about and now I understand the difference.
But it doesn't really help. It just give us an opportunity to wrap initial exception (IOException) into another one. The other exception MUST still be user-defined RuntimeException to avoid complining error (since Interface method has no any exceptions declared).
I have done almost the same what you said:
...
catch(IOException ioe) {
throw new MyRuntimeexception("Database problem...", io);
}
Do U really beleive that Sun will accept throwing Runtime Exception?
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad
Do U really beleive that Sun will accept throwing Runtime Exception?

Well, you do have to deal with the situation within the confines of what Sun require. As long as you do deal with it (e.g. dont just ignore the IOException) and document why you did what you did, then I think you should be OK.
As I said before: RuntimeException might be a valid exception since you aren't allowed to throw any other checked exceptions.
I would probably subclass RuntimeException so that I am throwing something that can be caught asside from all other RuntimeExceptions. (And I would catch it in my client).
And I would declare that my methods in the Data class throw this new exception so that it will appear in the javadoc.
Finally I would ensure that I documented clearly in my documentation to the examiner what I was doing and why.
Regards, Andrew
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,
Ok, that is what will do.
Thankx a lot!
Vlad
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic