On Wed, 11 Jun 2025 08:56:01 GMT, Volkan Yazici <vyaz...@openjdk.org> wrote:
>> Hello Volkan,
>>
>>> Earlier the regular file check was performed by FIS::new at subscription,
>>> hence, NSFE (yes, FIS::new throws NSFE when passed a not-regular file,
>>> e.g., a directory) was thrown at subscribe()
>>
>> The `NoSuchFileException` is a NIO construct and resides in `java.nio.file`
>> package. So the older `java.io.FileInputStream`'s constructor throwing a
>> `NoSuchFileException` felt odd to me. So I tried this:
>>
>>
>> jshell> new FileInputStream(new File("/tmp"))
>>
>>
>> that throws a `FileNotFoundException` (which is understandable) and not a
>> `NoSuchFileException`
>>
>>
>> | Exception java.io.FileNotFoundException: /tmp (Is a directory)
>> | at FileInputStream.open0 (Native Method)
>> | at FileInputStream.open (FileInputStream.java:185)
>> | at FileInputStream.<init> (FileInputStream.java:139)
>> | at (#1:1)
>>
>>
>> Was it something else in that test failure which was throwing the
>> `NoSuchFileException`?
>
> @jaikiran, your observation is correct. My explanation was worded poorly: I
> did not want to mean `NSFE` was thrown by `FIS::new`, instead I was stressing
> that _the exception_ was thrown at subscription-time. All in all, my point
> still stands: I could not move certain checks from `subscribe()` to
> `create()`, because of subscription- versus assembly-time difference in
> exception semantics. I will try to rephrase:
>
> * In the old version,
> * if the passed `Path` was associated with the default file system, and
> hence, supports `Path::toFile`, `FIS::new` of OIO was used and it throws
> `FNFE` of OIO.
> * Otherwise, `Files::newIS` of NIO was used throwing `NSFE` of NIO.
> * There was no `NSFE`-to-`FNFE` translation for the latter case.
> * Both `FIS::new`/`Files::newIS` invocations were at subscription-time.
> * In the new version, only `Files::newIS` is used, at subscription-time, with
> (hopefully) sufficient `NSFE`-to-`FNFE` translation to preserve the old
> exception semantics.
Hello Volkan, what you have looks good to me. Daniel too explained to me
yesterday why this proposed way is a better idea.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2139714335
