NX: How to deal with IOException when not declaired to be thrown.

[Jacques Bosch]

Hi guys.

// Provided interface code from sun.
public String[] readRecord(long recNo) throws RecordNotFoundException {

The provided interface for this method only throws a RecordNotFoundException.
But in the implimentation of this method, some of my code throws an IOException.
How do I deal with this since I can't change the method signature.
I've read something about wrapping it, but how do I go about doing that?
Thanx much!
Jacques

[james airey]

something like
try
{
methodThatThrowsIOException();
}
catch (IOException ioe)
{
throw new PermittedException(ioe);
}

[Jacques Bosch]

OK, That's easy.
But RecordNotFoundException is not really an IOException.
Isn't there a more elegant way of handling this?

[james airey]

not that I know of.
You could carry out some analysis on the server as to why you got an IOException, and then pass that up as a String in the exception.
Noting it in a log file would probably be a good idea too.
There was a post recently saying you can also determine the original Exception that was thrown when they are chained together - might be worth looking around for that, as it will allow the client to determine the cause too, and suggest appropriate action to the user.

[Ulrich Heeger]

Hi Jacques,
there are a lot of threads concerning the wrapping of IOException in another Exception. A lot of us decided to wrap them in a RuntimeException, thus you won't violate the DBAccess interface.
Greetings
Ulrich

[Jacques Bosch]

OK Cool, thanx!
But then how do I unwrap it again.
Or must I just do a search on the forumn

[Nicholas Cheung]

Hi Jacques,
In J2SE 1.4, there is a new concept "Exception Chain" invented.
You can use Exception.getCause() to get the original exception, but of course, you need to pass in the original exception into the wrapper exception.
Nick.

[Jacques Bosch]

OK. Thanx.
Will check it out.

[Murali Kurukunda]

Here is my $0.02 for your original questions. Obviously you can use the Exception Chaining that is added to Java 1.4. From Sun's Documentation on Throwable in 1.4
"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".
So basically you can wrap your IOException into the RecordNotFoundException, making the IOException object itself as cause of RecordNotFoundException, and now throw the RecordNotFoundException.
or
you can declare a member variable of type Exception in your observer class ( whichever class is interested calling your code in this particular method)
and whenever you catch this IOException in this method you set the member variable on the interested class, and that class can check whether the exception has occured and has the cause of that exception in its member variable. You might not need this approach, But I have used it once when I had to throw an exception in the run() method in my code.
Hope it doesn't confuse you.

[Peter Yunguang Qiu]

I wonder why Sun's DBAccess interface doesn't allow IOExceptions be thrown? There are two possibilities:
P1:
Sun's interface is a good design. There are good reasons to do that. We should think this problem positively and try to find suitable solution and reasonable, positive explanation.
P2:
Sun's interface is a stupid, bad design, but we have to follow it. We have to wrap the IOExceptions in a permitted exception and throw it again. Although it is not a good design, we have no other choice.
P3:
I don't know and don't care if the wrapping exceptions and Sun's interface is good design or not, I just have to follow Sun's requirement.
Now Java Ranch's solution is to wrap it and throw it again, like James Airey's posting.
If P1 is true, then what is the benefit of wrapping exceptions and Exception Chain? Why the Sun's interface design is a good design?
If the DBAccess interface allowed the IOExeptions be thrown, the design of the assignment would be better or worse?
It seems many people wrapping Exceptions due to P2 or P3.
Anyone has a good explanation?
Peter :roll:

[Andrew Monkhouse]

Hi Peter,
There are all sorts of possible reasons, some of which are:

Sun are attempting to simulate semi-clueless users (who have asked for something that is not really practical)

Sun are trying to see how well you can follow instructions - even when you don't necessarily agree with them and/or you can see a better way of handling the problem.

Sun are trying to see who well you handle a situation which is going to occur, but the instructions don't allow you to handle it in a standard manner.

Sun are trying to see how well you communicate your decisions about what you have done.

Regards, Andrew

[Philippe Maquet]

Hi Jacques,
I believe Ulrich is right (wrapping IOException in some RuntimeException of your own (DataException ?), instead of wrapping it in the existing checked exceptions. There are a few reasons of doing so :

As you noticed, RecordNotFoundException may have nothing to do with an IOException. And it's even worse for DuplicateKeyException.

Clients of your Data class would be harder to write : for instance, DuplicateKeyException normally clearly indicates an attempt to insert a duplicate record in the file. But if an IOException may be wrapped in it, the client code must test the cause of DuplicateKeyException before deciding what to do further.

At least with my instructions (URLyBird 1.2.1), it's *impossible* to wrap IOExceptions in the provided checked exceptions *AND* being consistent at the same time. Indeed, you may encounter some IOException in findByCriteria() which doesn't throw *any* exception which could be used as a wrapper !

Best regards,
Phil.

[Jacques Bosch]

I believe Ulrich is right (wrapping IOException in some RuntimeException of your own (DataException ?), instead of wrapping it in the existing checked exceptions.

So you mean rather than throwing a normal RuntimeException, I should rather extend RuntimeException with one of my own called DataException, or what ever. Just want to be clear.

[Philippe Maquet]

Exactly that !

[Jacques Bosch]

Thanx )

[Ulrich Heeger]

Hi everyone,
In the API its written within the doc for Throwable:

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.)

I think that's really parallel to our problem.
Greetings
Ulrich

[Wu Ming]

Originally posted by Jacques Bosch:

So you mean rather than throwing a normal RuntimeException, I should rather extend RuntimeException with one of my own called DataException, or what ever. Just want to be clear.

how to deal with this one? If you have IOException ?
public long createRecord(String [] data)

Would you please give a example?
THX.

[Jacques Bosch]

Like this:

} catch (EOFException e) {
throw new RecordNotFoundException(
"The specified record number (" + recNo + ") was not found");
} catch (IOException e) {
throw new RuntimeException(
"IOException occurred while reading record : " + e.toString());
}

Or, once you have extend RuntimeException to something like IORuntimeException, like this: (I think )

} catch (EOFException e) {
throw new RecordNotFoundException(
"The specified record number (" + recNo + ") was not found");
} catch (IOException e) {
throw new IORuntimeException(
"IOException occurred while reading record : " + e.toString());
}

[Andrew Monkhouse]

Hi Wu,
I would recommend the second option Jacques' showed. Using the first makes it more difficult to catch the exception later (assuming you may want to catch it somewhere) - you would have to catch the generic RuntimeException (which isn't really meant to be caught) and check it's cause to see if this is the exception you really meant to catch .
Regards, Andrew

[Anton Golovin]

or you can have your method throw an IOException as well.

[mike acre]

In reply to Anton.

I think the point is that we implement the interface provided.
I don't think changing it qualifies. Certainly with UyB.