• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Exception handling - IOException not in DB interface

 
Jared Chapman
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:




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.
    Ranch Hand
    Posts: 63
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 81
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
    Ranch Hand
    Posts: 63
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Greenhorn
    Posts: 19
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 81
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Greenhorn
    Posts: 19
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 81
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Greenhorn
    Posts: 19
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 175
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 530
    1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Ranch Hand
    Posts: 181
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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:

    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 ]
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic