Exceptions On File I/O Interface Methods

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:

public interface DocumentRamrod<T>
{
public T openDocumentFile(File file) throws FileNotFoundException;
}

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

public class MyRamrod implements DocumentRamrod<OneLineOfText>
{
public OneLineOfText openDocumentFile(File file) throws FileNotFoundException
{
return new OneLineOfText(new BufferedReader(new FileReader(file)).readLine());
}
}

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:

public class MyRamrod implements DocumentRamrod<OneLineOfText>
{
public OneLineOfText openDocumentFile(File file) throws FileNotFoundException
{
try
{
return new OneLineOfText(new BufferedReader(new FileReader(file)).readLine());
} catch (IOException ex)
{
Logger.getLogger(MyRamrod.class.getName()).log(Level.SEVERE, null, ex);
}
}
}

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

public interface DocumentRamrod<T>
{
public T openDocumentFile(File file) throws FileNotFoundException, IOException
}

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

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,