[Kaffe] java.io.File(Input|Output)Stream question.

[Moses DeJong]

On Fri, 12 Feb 1999, Godmar Back wrote:

> > 
> > On Fri, 12 Feb 1999, Godmar Back wrote:
> > 
> > > > 
> > > > On Fri, 12 Feb 1999, Godmar Back wrote:
> > > > 
> > > > > > 
> > > > > > Ok, here is a quick shot at that.
> > > > > > 
> > > > > 
> > > > > This tests only one case, though.
> > > > 
> > > > The problem is that they throw a FileNotFoundException. The correct
> > > > thing to do in this case is to throw an IOException. Then in the case
> > > > where the file does not exist a FileNotFoundException can be thrown.
> > > > A FileNotFoundException is derived from IOException so there would
> > > > be no problem there. In the current JDK and Kaffe implementations
> > > > an IOException is rethrown as a FileNotFoundException which is
> > > > just plain wrong.
> > > > 
> > 
> > Well, if it is a bug then why not fix it? The FileOutputStream class
> > does not have this bug. If you look at the throws clause on the
> > FileOutputStream stream you will see that is throws an IOException
> > not a FileNotFoundException. This means you can implement a
> > FileOutputStream correctly on unix systems but there is no way
> > to implement a FileInputStream correctly. This change will not
> > stop you from implementing FileInputStream on a windows box but
> > is does stop a correct implementation on a unix system.
> > 
> 
> First, we shouldn't fix Sun's bugs if that introduces interoperability
> problems.  Second, I still would not classify this as a bug.
> Saying that FileOutputStream throws an IOException, and FileInputStream
> throws FileNotFoundException instead is at best an inconsistency.

I think a FileInputStream should have this a it's throws clause
"throws IOException". In the case where a file does not exist the
implementation could then throw a FileNotFoundException. If the
file does exist but it is not readable it could throw a
FileNotReadable exception (as long as FileNotReadable is a subclass
of IOException). If the file exists but the dir is not readable
(of course I do not know how you could find out that the file existed
if the dir was not readable), you could throw a DirNotReadable or
whatever class you wanted to throw as long as it was derived from
IOException there would not be a problem. The real issue here is
that the throws clause on the method should throw the more general
exception type and not the more detailed type (the FileNotFoundException). 

> I'm still not quite clear on what you want us to do (or what you want
> to do yourself.)  Am I right that you want FileInputStream to only
> throw a FileNotFoundException if the file is not there, and throw an
> IOException if you don't have the permissions to read it?
> What do you want to do if the file is there, but you're not allowed to
> read the directory in which it resides?

Well, ok then why is there is difference for the FileOutputStream?
You can either open it for writing or you can't.

> I just don't see what practical benefit that would have.  You can either
> open it or you can't.  The actual error message is part of the exception 
> message, so the user would know whether it's permission denied or 
> file not found or whatever.  Since java doesn't support chmod or somesuch
> you couldn't even change the permissions on a file is you detect you
> can't read it because of permission problems.

No, this is not correct. The "lowest common denominator" would be
throwing an IOException is this case. Grouping all possible errors under
IOException would be the correct thing to do. Grouping all error under
FileNotFound even when the errors have nothing to do with not finding
the file is just plain wrong.

mo
 
> Implementing Java's claim of cross-platform compatibility requires to either
> restrict yourself to a lowest common denominator (which is what they do
> by grouping all possible error cases under "FileNotFoundException") or it
> requires you to define new cross-platform abstractions (File.listRoots(),
> for example).  Since the latter hasn't happened for FileInputStream,
> I think it's okay to stick to the former approach.
> 
> 	- Godmar
> 
>