Exception handling - IOException not in DB interface

[Jared Chapman]

Hello all. I have spent a bit of time pondering a little problem with exception handling in this program, but (thanks to the help of this forum) I think I have a solid solution.

The DB.java interface provided in my assignment specifies the following methods:

public String[] read(int recNo) throws RecordNotFoundException;
 
public void update(int recNo, String[] data, long lockCookie)
                             throws RecordNotFoundException, SecurityException;
 
public void delete(int recNo, long lockCookie)
                             throws RecordNotFoundException, SecurityException;
 
public int[] find(String[] criteria);
 
public int create(String[] data) throws DuplicateKeyException;
 
public long lock(int recNo) throws RecordNotFoundException;
 
public void unlock(int recNo, long cookie)
                             throws RecordNotFoundException, SecurityException;

PROBLEM:
This interface (provided by Sun) doesn't specify IOException. That means that in my Data class, I can't throw IOExceptions, even though I am constantly interacting with a database file.

I have read some good threads in this forum suggesting solutions to this problem. For example:

use runtime exceptions

cache the database - eliminates the need for IO (until the cache needs to be written back to file, of course)

use exception chaining

MY SOLUTION:

For these methods:

public String[] read(int recNo) throws RNF, Security
public void update(int recNo, ...) throws RNF, Security
public void delete(int recNo, ...) throws RNF, Security

1. catch the IOException
2. log the IOException
3. chain the IOException to a RNFException and throw
*after all, the IOException prevented the record from being
found

For these methods:

public int[] find(String[] criteria)
public int create(String[] data) throws DuplicateKey

1. catch the IOException
2. log the IOException
3. return null or -1, depending on the method
4. document (for other programmers) what these return values mean

For these methods:

public long lock(int recNo) throws RNF
public void unlock(int recNo, long cookie) throws RNF, Security

1. NO SOLUTION NEEDED: no I/O done in these two methods

Am I looking at this correctly, or am I missing some point?

[Matt Sheehan.]

For these methods:

public int[] find(String[] criteria)
public int create(String[] data) throws DuplicateKey

1. catch the IOException
2. log the IOException
3. return null or -1, depending on the method
4. document (for other programmers) what these return values mean

In SCP & D by Sierra and Bates, it says:

Don't Return Error Codes
This is Java. Using error codes as return values, rather than using exceptions, is a Really Bad Idea. We're pretty sure your exam assessor knows that.

Otherwise, I think it looks good.

Matt

[Jared Chapman]

Hey Matt, thanks for the reply!

Don't Return Error Codes
This is Java. Using error codes as return values, rather than using exceptions, is a Really Bad Idea. We're pretty sure your exam assessor knows that.

I agree, this is not a desireable situation. But since I am not allowed to change the DB interface provided by sun, the find(String[]) method proviede by Sun does not throw any exceptions, and i do not wish to throw a runtime exception, i cannot think of another way to pass the information along that an error occurred.

Suggestions?

[Matt Sheehan.]

Hi Jared,

I don't know of any way to get exceptions through the interface besides what you noted above. Personally I chose the runtime exception. I throw a FatalException wherever I see exceptions that shouldn't happen or stuff that I don't think is recoverable, including I/O errors. The GUI then catches it, tells the user, and exits. This may not be the best approach, but its simple and consistent.

Matt

[Rob Shields]

Hi

IMO throwing unchecked exceptions is far more desirable than using error codes. If you use error codes, you're taking a journey back in time.

It may not be as desirable as throwing checked exceptions, but part of the assignment is to overcome these obstacles in the best possible way, given the constraints.

Rob
[ October 13, 2004: Message edited by: Rob Shields ]

[Jared Chapman]

Thank you both for your help. Your comments have raised a few more question:

1. Does an IOException have to be fatal? For example, let's say the user has already successfully connected to a local database, and eventually they attempt to update a record. While attempting to update, an IOException is thrown. Should this cause the program to terminate, or should the user simply be informed that the record could not be updated, and the exception logged?

I can see where getting an IOException while trying to initially connect to a database file would be fatal. But what would cause an IOException when the user has already sucessfully connected to the file? Would it be a persistant or random problem? If it were a persistant problem, then the program should terminate. But if it were a random case, the user should be allowed to continue, after the problem has been dealt with.

2. Let's say that I decide to go with runtime exceptions for the two methods in question. Would it then be advisable for me to use runtime exceptions in all methods that can throw an IOException, (i.e. would my design be inconsistent if I used exception chaining for the first three methods)?

[Rob Shields]

Hi Jared,

I'm currently facing the same questions as you, here are some of my thoughts.

I think that an IOException is usually pretty terminal (e.g. someone removed the hard disk or network cable, or some low level OS failure), so there may be little point trying to recover from it. One execption I can think of (of which there are probably many more) is EOFException, which is-an IOException, thrown from RandomAccessFile read methods if you try to read beyond the end of the file. In my case, that should never happen, so if it does, I'll probably choose exit too. Popping up a message in the client telling the user that the application will exit would probably be acceptable, like Matt suggested. One other option I thought of would be an Abort, Retry, Fail box, but that would require more code.

With regard to your other question, consistency is important for code maintainability. Also, it may not be appropriate to nest certain exceptions e.g. an IOException nested within a RecordNotFoundException might not make sense.

Rob
[ October 13, 2004: Message edited by: Rob Shields ]

[Jared Chapman]

Hi Rob,

I agree - an EOF exception should never happen. It's an unchecked exception, so it will only be thrown because of an error on the part of the programmer.

As for not using error codes, I actually got the idea from
this thread.

Near the end, Max Habibi states:

This is entirely consistant with the Java way of doing things. For example, the ArrayList.add() method returns a boolean that returns true if the add was successful. If you don't check that result, then the ArrayList.add() might quietly fail. Is that the ArrayList's fault? No, IMO, it's not. The API told you have to use the method: it's up to you to do so.

Wouldn't life be easier if we could use any checked exceptions? Oh the joys of programming...

[Rob Shields]

Hi

Wouldn't life be easier if we could use any checked exceptions

Indeed.
I wonder what a C# developer would do - they don't have checked exceptions

Rob

[Inuka Vincit]

In my implimentation I am cacheing the file. But still the Update Create Delete methods need to deal with the IOException. I am using a method similar to Matts by using unchecked exceptions, notifying the user and then exiting.

Although I was going to chanin the exceptions as RNF exceptions, I felt that it was a bad idea because any exceptions other than RNF would indicate a fatal error that you need to deal with cleanly and who ever deals with that error needs to handle it. I realy dont think using a error codes is a bad idea though. It realy depends on how you feel about the design.

Whatever path you choose be consistent, it is such PITA to use other ppls libararies that dont have consistent implementations even if they are powerful.
[ October 13, 2004: Message edited by: Inuka Vincit ]

[Anton Golovin]

Originally posted by Inuka Vincit:
In my implimentation I am cacheing the file. But still the Update Create Delete methods need to deal with the IOException. I am using a method similar to Matts by using unchecked exceptions, notifying the user and then exiting.

Although I was going to chanin the exceptions as RNF exceptions, I felt that it was a bad idea because any exceptions other than RNF would indicate a fatal error that you need to deal with cleanly and who ever deals with that error needs to handle it. I realy dont think using a error codes is a bad idea though. It realy depends on how you feel about the design.

Whatever path you choose be consistent, it is such PITA to use other ppls libararies that dont have consistent implementations even if they are powerful.

[ October 13, 2004: Message edited by: Inuka Vincit ]

Hi, Inuka! I also put records in a cache at the start of the program. So where IO is concerned, instead of indicating a failure of the application, I indicate the failure of the operation. The update to the data file must happen before the update to the cache, so the program can run even with IOExceptions.

[Daniel Simpson]

Gosh, I really hate to bring up this post again because I know that this has been discussed to death, but I want to make sure that I read this right and my solution sounds okay. I am caching my records into an arraylist, but when I update, create, and delete a record, I first do so in the data file before updating my cache. So what I have read, would it be okay to do something like this:

//finds the offset of when the record starts
        int recordOffset = schemaLength + (recordLength + flagLength) * recNo;
        try {
            dbReader.seek(recordOffset);
        }
        catch(IOException ioEx) {
            throw new RuntimeException("Unable to read offset in file.");
        }  

Is that how I would do that? Chain my IOException to a RuntimeException? I first thought about chaining it to a RecordNotFoundException, but that isn't really the purpose of the RNFEx. My doc says:

Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file.

So I don't think I should chain it to a RNFEx for errors while reading bytes. Does this solution sound okay? Is it okay that I throw a RuntimeEx? Or would it be better to subclass RNFEx? And catch the IOException and rethrow an IORNFEX? Thank you!
[ November 21, 2004: Message edited by: Daniel Simpson ]