Open StefanOltmann opened 1 year ago
@StefanOltmann, it's just a better alternative to opening a file and catching IOException thrown due to missing permission, right? Not arguing about the necessity of an API, just trying to figure out a particular use case.
@fzhinkin Exception handling is always painfully slow. So using Exceptions as part of the workflow code (for example catching NumberParseException so test if some string contains a number) is considered an anti pattern.
The file system already has the information about the file permissions and can be accessed in a fast way.
I described a use case for that in my first post. I want to directly write a sidecar for read-only files without catching an exception first. Exceptions slow down the process by a lot.
The problem with such a test is that a file may change its permissions in between getPermissions/getMetadata
call and openFile
call, so having good permissions initially does not guarantee a successful opening (which may still throw an exception).
Speaking of performance, I'm not sure that catching an exception will be slower than a call fetching file metadata (as the latter requires a native call that, in turn, makes a system call). But as an alternative, open may return null on failure instead of throwing an exception.
At least java.io.File.canRead()
is faster than handling the exception.
A permission change between the check and openFile will be rare (as there are only milliseconds in between), but if it happened and the file is not readable throwing an exception is correct behavior. I think it’s a better than returning null.
I don’t seek to avoid exceptions at all costs, I’m just against using them in the regular workflow as Exception handling in Java is painfully slow.
@fzhinkin Any new thoughts on this?
@fzhinkin is currently unavailable.
Filesystem support (which includes extending metadata beyond what we are providing currently) is part of our stabilization roadmap, and high chance this request will be incorporated into the support provided
I require an equivalent for
java.io.File.canRead()
andjava.io.File.canWrite()
to determine whether it's possible to read from or write to a file. This information is important in the case of Ashampoo Photos to decide whether to directly write metadata to an image file or use a sidecar file.