• Post Reply Bookmark Topic Watch Topic
  • New Topic

Exceptions on File I/O Interface Methods  RSS feed

 
Bartender
Posts: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm wondering about the use of exceptions to handle errors that might occur during file I/O when the I/O is done by a method implementing an interface's method. The idea is for the interface to provide a uniform way for application code to read (and write, though I'm not addressing that in this post) a document from a file, given a File object that specifies the on-disk location of the document. The "document" can be an instance of any class the application programmer wants it to be, provided that it can be created from a file stored on disk. Here's the interface definition:



A simple implementation, when T is a class that just holds a String, might look like this
(Please overlook the fact that there is no call to the BufferedReader's close method, as it's not needed for this example.):



But, that one line where the file is read (Line 5) might generate an IOException.

To cope with it, I could add a try-catch to the implementation like this:



Or, I could add that to the list of exceptions defined for the method in the interface, like this:



But that's where I'm getting nervous, as it makes me realize that, with an infinite number of possible implementations of openDocumentFile, I can't predict what all the exceptions thrown might be.

So, my question is: should I have openDocumentFile simply throw Exception, and let the application programmer sort out which one(s) might actually be thrown, should I keep listing them as it become clear which ones are likely to be thrown, or should I not have openDocumentFile throw any exceptions and let the application programmer deal with it in the implementation of openDocumentFile (with try-catch blocks, etc.)? In Good Old C, I'd have passed back a null to indicate some general failure, with the various callers up the call-stack having to either deal with it or pass that back themselves (until some routine up the stack finally did deal with it), but that seems like an approach the whole exception mechanism was designed to avoid.

For generality's sake, I'm thinking the right choice is to have openDocumentFile throw Exception, and let the application programmers decide which subclasses of Exception they really want to deal with. But I have learned to be humble about the things I think, where Java is concerned, so any advice on this would be appreciated, as always.

 
Bartender
Posts: 2087
44
Firefox Browser IntelliJ IDE Java Linux Spring
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe something here can help you.
A link

I don't think declaring FileNotFoundException in your interface is a good idea.
Other things may go wrong when reading a file than the file not being present. Like lack of read permissions.
It would be better if you declared it as throwing IOException.
BTW IOException is the superclass of FileNotFoundException, so writing throws FileNotFoundException, IOException is redundant.
 
Stevens Miller
Bartender
Posts: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pawel Pawlowicz wrote:IOException is the superclass of FileNotFoundException, so writing throws FileNotFoundException, IOException is redundant.


Good point. The actual implementation that alerted me to the unpredictability of what exceptions might be thrown was one where the on-disk storage was in an XML file:


Line 7 can throw an ArrayIndexOutOfBoundsException (which is a subclass of RuntimeException, which is a subclass of Exception). That can easily happen if the file passed to openDocumentFile isn't an XML file. In a situation like that, I want the application to be able to tell the user, "Hey, you seem to have tried to open a file that's not what I'm looking for," and proceed with graceful execution. That doesn't seem like the kind of thing that belongs in the implementation of openDocumentFile. I think it belongs in the application code that called openDocumentFile. But, that means the calling code has to know that openDoucmentFile encountered a problem. Thus, I am asking my question about how best to let the application code know that openDocumentFile failed.

The link you provided (and thanks for that; I'll re-read the stuff in Bloch about exceptions) offers, as one option, the use of a special return value to indicate an error, but that's not much different, imho, from returning null (which the same page suggests is a bad idea). Sure, you don't risk a null-pointer exception, but you still have to check for it, which I am thinking the exception mechanism renders unnecessary.
 
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Declaring an interface to throw a general Exception is almost always a bad idea. Think about what you might expect a method to throw.

I think it's fair to expect that *anything* dealing with i/o might throw an IOException. Sure enough, whenever I write a method called something like load, save, open, close, read or write, it almost always declares that it throws IOException.

Should you be nervous that other types of exceptions may occur? Not really. Take a look at the Exception class API, and look at all the direct known subclasses. Most of them are used in very unlikely or obscure cases, or should have been subclasses of RuntimeException anyway. The only exception I can think of off the top of my head that is marginally interesting, that I don't usually rethrow as an IOException anyway, is InterruptedException.
 
Stevens Miller
Bartender
Posts: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That makes good sense, Stephan. If I don't add "throws ArrayIndexOutOfBoundsException" to the openDocumentFile method signature, can higher level methods in the application still use try-catch to catch that exception? That is, if a() calls b() calls c() calls openDocumentFile(), can I wrap a() in a try-catch block and handle the ArrayIndexOutOfBoundsException thrown from within openDocumentFile() in that block?
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As for your example, I think having XMLDecoder.readObject() throw an ArrayIndexOutOfBoundsException was an incredibly bad idea. You can work around this problem by doing the following:
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stevens Miller wrote:That makes good sense, Stephan. If I don't add "throws ArrayIndexOutOfBoundsException" to the openDocumentFile method signature, can higher level methods in the application still use try-catch to catch that exception? That is, if a() calls b() calls c() calls openDocumentFile(), can I wrap a() in a try-catch block and handle the ArrayIndexOutOfBoundsException thrown from within openDocumentFile() in that block?


You don't have to declare RuntimeExceptions. You can always try to catch them without using a method that declares them. But see my post above for what I consider a more elegant solution.
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think it's legitimate to wrap these exceptions in an IOException, because the exceptions occurred because the input file had a bad format.
 
Stevens Miller
Bartender
Posts: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:You don't have to declare RuntimeExceptions. You can always try to catch them without using a method that declares them. But see my post above for what I consider a more elegant solution.


Thanks, Stephan. That is, indeed, an elegant approach. I would not have thought of that myself, but I'm going to use it.

This is the most helpful online forum I've ever found.
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm glad it helped
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!