Closed Bodigrim closed 9 months ago
Essentially I'm asking to do what base
does in such cases:
openFile :: FilePath -> IOMode -> IO Handle
openFile fp im =
catchException
(openFile' fp im dEFAULT_OPEN_IN_BINARY_MODE True)
(\e -> ioError (addFilePathToIOError "openFile" fp e))
It catches the underlying IO exception and rethrows it, forcefully setting ioe_filename
via addFilePathToIOError
.
Yes, we should try to mimick base as much as possible.
I noticed in https://github.com/hasufell/file-io/actions/runs/7500925884/job/20420565223#step:5:295 that the exceptions seemingly do not set
ioe_filename
field ofIOException
. That's explainable:mkFD
(which is responsible for this particular error) does not have a filename at hand.A simple (crossplatform!) reproducer is this:
It would be painful to debug such write lock in a real-life application, because the error message does not mention which filename is locked.
Could functions in
file-io
catch and re-throwIOException
s, forcefully settingioe_filename
if empty?