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

[Godmar Back]

> 
> On Thu, 11 Feb 1999, Tony Kimball wrote:
> 
> > Quoth Moses DeJong on Thu, 11 February:
> > : Is there some other kind of IOException
> > : that could happen while opening a file for writing that would not
> > : happen while opening a file for reading.
> > 
> > Paying strict attention to your 'could' and 'would' semantics,
> > you could get EPERM in one case while you would not in the other.
> > But, vice versa contrariwise, on the other hand.  
> 
> Oh, I get it now, you are saying that a file writer could hit a unix
> file that does not have write permission. If that was the case then the
> reader could also run into a file without read permission. So I guess
> the problem is that there would be no way to tell if a file existed but
> was not readable when a FileNotFoundException is thrown by a reader.
> So, this does seem like a bug in the Sun spec after all. Does this
> mean we should change the implementation of Kaffe's FileInputStream to
> throw an IOException instead of a FileNotFoundException. I took a look
> the Kaffe's impl of FileInputStream and it does throw an IOException
> but it then catches the IOException and rethrows it as a
> FileNotFoundException.  A less specific exception like an IOException
> should not be rethrown as a more specific exception like a
> FileNotFoundException. It seems like this is a bug in the Sun JDK docs
> and implementation. Does anyone agree with me?
> 

I think a possible way would be to write a set of simple testcases
and run it against Sun's implementation, both 1.1 and 1.2.  I.e., test 
non-existing, read- and write protected files.
Then use these results and tweak Kaffe appropriately.

When the spec says a method throws such and such, then that's in their
implementation practice not more than a rough guideline anyway.

	- Godmar