Exceptions thrown from interface provided by Sun?

[Satish Avadhanam]

Hi Guys,
As I was trying answer a question in a different post I got a doubt. Sun's provided interface methods throws business specific exceptions and no method throws IOException or any other Exception.

// Reads a record from the file. Returns an array where each
// element is a record value.
public String [] readRecord(long recNo)
    throws RecordNotFoundException;

The Data class must implements this method. Now, all IO operations using RAF throw IOException. Now we cannot throw IOExceptions from any of the methods. So what can we do? I mean just catch Exception in the readRecord method and exit the application? Is there any way to pass the exception to the client?
Appreciate any input, thanks.

[Pavel Tcheshmedjiev]

Hi Satish,
There are different approaches.
What about catching the IOException and throwing a new RNFE, specifying its message or using Exception chaining.

[George Marinkovich]

Hi Satish,

Originally posted by Satish Avadhanam:

Sun's provided interface methods throws business specific exceptions and no method throws IOException or any other Exception.

// Reads a record from the file. Returns an array where each
// element is a record value.
public String [] readRecord(long recNo)
    throws RecordNotFoundException;

The Data class must implements this method. Now, all IO operations using RAF throw IOException. Now we cannot throw IOExceptions from any of the methods. So what can we do? I mean just catch Exception in the readRecord method and exit the application? Is there any way to pass the exception to the client?

There are two usual ways:
1) Catch IOException, but throw RecordNotFoundException(String message) where message reflects the nature of the problem that caused the IOException.
2) Catch IOException, but throw some RuntimeException (or subclass thereof). The RuntimeException doesn't need to be declared in the throws list.
1) Pros:
Makes client handle the exception because it's in the throws list
1) Cons:
Does it dilute (or pollute to put it more strongly) the meaning of a RecordNotFoundException to throw one because of an IOException?
2) Pros:
Can throw a more meaningful subclass of RuntimeException whose name reflects the problem perhaps better than RecordNotFoundException.
2) Cons:
The client doesn't need to check for the RuntimeException.
There are people who like 1 and dislike 2, and then there are people who like 2 and dislike 1. I'm in the first camp.

[Satish Avadhanam]

Thanks Pavel.

Originally posted by Pavel Tcheshmedjiev:
Hi Satish,
There are different approaches.
What about catching the IOException and throwing a new RNFE, specifying its message or using Exception chaining.

First one sounds good to me. But second one, how can you do exception chaining when readRecord is not allowed to throw any other exceptions. What I understood about exception chaining is if a method do not catch the exception, it throws it. The calling method if it feels not catching the exception it throws it...so it goes all the way up where the exception actually is caught. The thing here is we cannot throw right?
Please correct me if I'm wrong. Thanks.

[Satish Avadhanam]

Thanks George. By the time I read Pavel's message and posted, you made it very clear.
Yeah, will stick with one only
[ March 10, 2004: Message edited by: Satish Avadhanam ]

[Simon Ingram]

Yes, thanks again George, a very clear and concise answer.
Simon

[Pavel Tcheshmedjiev]

Hi guys,
I guess the exception chaining is an addition to George's 1)
We catch the IOException and throw a new RNFE by using RNFE(Thowable cause) constructor, where cause is our caught IOException.
So when we catch the RNFE we can use RNFE.getCause() to identify what was the cause.
What about this approach ? I'm using it in my implementation.

[George Marinkovich]

Hi Pavel,

Originally posted by Pavel Tcheshmedjiev:
Hi guys,
I guess the exception chaining is an addition to George's 1)
We catch the IOException and throw a new RNFE by using RNFE(Thowable cause) constructor, where cause is our caught IOException.
So when we catch the RNFE we can use RNFE.getCause() to identify what was the cause.
What about this approach ? I'm using it in my implementation.

I like it. Using exception chaining is a good practice and I probably should have added a RNFE(Throwable cause) constructor in addition to the RNFE(String message) one.
On the other hand, I really did convince myself that an IOException in any of the database methods really could be meaningfully translated to a RecordNotFoundException. In other words, if the read method really did throw an IOException then as far as the client cared the record was not found and the client would probably take the same action in this case as the client would for the case where an attempt to read a deleted record was made. So while I didn't think the client really cared about the underlying reason the record was not found, I did log the original exception to assist in debugging the problem.

[Pavel Tcheshmedjiev]

Hi George,
Your arguments sound quite convincing
I'd like to ask if you documented them or it is beyond the exam's requirenments.
[ March 10, 2004: Message edited by: Pavel Tcheshmedjiev ]

[George Marinkovich]

Hi Pavel,

Originally posted by Pavel Tcheshmedjiev:

I'd like to ask if you documented them or it is beyond the exam's requirenments.

I did discuss error handling in the design choices document, where the technique I followed of wrapping exceptions is covered briefly. I didn't really comment about this in the code, because well, the code shows the IOExceptions being caught and the RecordNotFoundExceptions being thrown. I'm not sure what else I could have said in a comment that the code didn't say better.

[Gaz Smith]

Just to stir thinks up a bit... :roll:
My create method doesn't throw a RecordNotFoundException, only DuplicateKeyException
My findByCriteria method throws no checked exceptions at all.(such as RecordNotFoundException)
As a result I went for option 2. I decided it was better to take a consistent approach and so I catch the IOExceptions and re-throw my own subclass of RuntimeException chained with the IOException. This can then be extracted as and when. Obviously this is documented.(which seems to be the key point whichever option you choose! )

[Mark Smyth]

This is what I did not sure if it is good or bad

  
class LocalDataClient implements DataClient
DBMain data;
    getRoom(int recordNo)throws IOException, RecordNotFoundException{
        try {
             data.lock(recordNo);
             data.read(recordNo);
             data.lock(recordNo);
         }
         catch(RecordNotFoundException rnfe){
             //Actually a record not found
             if(rnfe.getCause()==null throw rnfe;
             //Wolf in sheeps clothing
             if(rnfe.getCause() instanceof IOException)  
                 throw (IOException) rnfe.getCause();
         }  
    }
}

Horrendous looking code by any standards but it does work. I had an idea at some stage to make RecordNotFoundException extend IOException but it abandoned it and I can't remember why exactly. It doesn't say you cant do that anywhere, though I would guess that as a RecordNotFoundException is in no way related to IOException would be a bit of a no, no perhaps?
[ March 10, 2004: Message edited by: Mark Smyth ]

[Satish Avadhanam]

Guys, thankyou all for your inputs. Now, I can see that there are really many ways of handling this.
We can continue the discussion if anyone likes to talk about other ways of handling the situation.
Thanks

[alzamabar]

Originally posted by Pavel Tcheshmedjiev:
Hi guys,
I guess the exception chaining is an addition to George's 1)
We catch the IOException and throw a new RNFE by using RNFE(Thowable cause) constructor, where cause is our caught IOException.
So when we catch the RNFE we can use RNFE.getCause() to identify what was the cause.
What about this approach ? I'm using it in my implementation.

I like it too.