Better error reporting for IOFile, esp. for OpenEXR writes #2780
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Filesystem::IOFile constructor now upon an error opening the file will set the error message appropriately. Move IOProxy::error() implementation from inline to be in filesystem.cpp to hide its details, use a static mutex to make error set and retrieval be thread-safe (we presume that the rare chance that multiple threads will be setting or getting IOProxy errors simultaneously are rare enough that it's not a thread performance issue, and if the user is getting file I/O errors, a bit of minor locking is the least of their worries). Better checking of these errors in OpenEXR input and output open operations. Hopefully this means that exr file I/O errors will percolate up more helpful error messages.
|
I'm using vcpkg to build oiio on windows, but the version available on vcpkg is still 2.1.16.0. It would be good for the long term to see if the vcpkg patches could be integrated in oiio. |
lgritz
added a commit
to lgritz/OpenImageIO
that referenced
this pull request
Dec 10, 2020
…ftwareFoundation#2780) Filesystem::IOFile constructor now upon an error opening the file will set the error message appropriately. Move IOProxy::error() implementation from inline to be in filesystem.cpp to hide its details, use a static mutex to make error set and retrieval be thread-safe (we presume that the rare chance that multiple threads will be setting or getting IOProxy errors simultaneously are rare enough that it's not a thread performance issue, and if the user is getting file I/O errors, a bit of minor locking is the least of their worries). Better checking of these errors in OpenEXR input and output open operations. Hopefully this means that exr file I/O errors will percolate up more helpful error messages.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Filesystem::IOFile constructor now upon an error opening the file will
set the error message appropriately.
Move IOProxy::error() implementation from inline to be in
filesystem.cpp to hide its details, use a static mutex to make error
set and retrieval be thread-safe (we presume that the rare chance that
multiple threads will be setting or getting IOProxy errors
simultaneously are rare enough that it's not a thread performance
issue, and if the user is getting file I/O errors, a bit of minor
locking is the least of their worries).
Better checking of these errors in OpenEXR input and output open
operations. Hopefully this means that exr file I/O errors will
percolate up more helpful error messages.