We have to define some specified IO exception type.

[iseki0]

In Java, we have the following IOExceptions that relate with file system:

• java.io.FileNotFoundException
• java.nio.file.AccessDeniedException
• java.nio.file.DirectoryNotEmptyException
• java.nio.file.FileAlreadyExistsException
• java.nio.file.NoSuchFileException
• java.nio.file.NotDirectoryException
• java.nio.file.NotLinkException

Although I curious why wethey leave a NotDirectoryException alone, but at least we have some detailed exception can be used to detect what's happened during runtime. And appearantly, the most of OSes can implement it.

So, maybe we can have a discuss of what kinds of detailed FileSystem I/O exceptions we need.

What do you think of? @fzhinkin

[05nelsonm]

I did exactly this with kmp-file.

There is a bit of nuance to it all because

1. Android does not have those exceptions available until API 26
2. As wonderful a job that the MinGW maintainers have done, there are some edge cases that need smoothing out when on Windows to ensure the same exception as Unix is thrown given the conditions. This affects Java, Node.js, and Kotlin/MinGW.
   • E.g. Creating a directory where the parent is actually a regular file, not a directory. Windows returns errno of ENOENT but Unix returns ENOTDIR, so must always check the parent directory on ENOENT for if it is a directory then change error to ENOTDIR.

Kotlin actually re-defines a couple FileSystemException types in package kotlin.io because of the Android availability issue. I typealias my commonMain expect/actual to what was available there, but had to define some of them myself in kmp-file.

Mapping exceptions is pretty straight forward, e.g.:

• Jvm Nio
• Jvm Android API 21+ ErrnoException
• Js/WasmJs Node
• Native posix errno
• Native MinGW GetLastError

Also must decide whether to use FileNotFoundException, or NoSuchFileException. Throwing either or in different parts of the codebase would be awful. I chose to stick with FileNotFoundException and map the nio exception to it because it was already defined in my API (the same being true for kotlinx-io, I believe).

Another thing to look out for is SecurityException. I chose to always map it to AccessDeniedException and add the SecurityException as a suppressed exception.

[iseki0]

Currently we'd better to avoid use the MinGW implementation, so we just need to focus on the Windows API.

[05nelsonm]

Currently we'd better to avoid use the MinGW implementation, so we just need to focus on the Windows API.

There are some things where MinGW APIs are OK to use in Kotlin/Native, but yes I have found them lacking greatly in terms of behavioral parity with Unix. Again though, that is only applicable to Kotlin/Native. The behavioral differences on Windows still exists for Java and Node.js where avoidance of MinGW APIs is not a solution. It must be dealt with.

[iseki0]

Please check the Unicode supporting. Especially on Windows before Windows 11

There are some things where MinGW APIs are OK to use in Kotlin/Native

[fzhinkin]

I don't really think the library should provide such a rich set of exceptions. Instead, the API should be built around rich errors, once they become available.

[iseki0]

@fzhinkin Personally I don't think the rich errors is a good idea, since the Kotlin already have exception used widely. But exception or rich erros is not the key problem, in this thread.