Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove throw from gdaljl_errorhandler #153

Merged
merged 2 commits into from
Jun 13, 2023
Merged

Conversation

maxfreu
Copy link
Contributor

@maxfreu maxfreu commented Jun 2, 2023

The throw interrupts control flow on the C side, e.g. suppressing the closing of file descriptors when the error is caught by julia. This PR removes it, but leaves the error handler in place, so that printing by GDAL is suppressed. Furthermore, maybe_throw now also throws on fatal errors. Locally, all test pass.

ref rafaqz/Rasters.jl#455

The throw interrupts control flow on the C side, e.g. suppressing the closing of file descriptors when the error is caught by julia.
visr added a commit to yeesian/ArchGDAL.jl that referenced this pull request Jun 2, 2023
This is all that is required to fix tests after JuliaGeo/GDAL.jl#153
src/error.jl Outdated Show resolved Hide resolved
visr added a commit to yeesian/ArchGDAL.jl that referenced this pull request Jun 2, 2023
This is all that is required to fix tests after JuliaGeo/GDAL.jl#153
Co-authored-by: Martijn Visser <[email protected]>
@maxfreu
Copy link
Contributor Author

maxfreu commented Jun 3, 2023

Oh, before I forget: There is an alternative how errors could be handled. One could have a global const ref to a GDALError that gets passed as user data to the registered error handler function and gets updated inside. This would require registering the gdaljl_errorhandler at load time I think, because the address the ref points to will always be different. But all this sounds bad and should only be considered if it is really necessary.

@visr
Copy link
Member

visr commented Jun 3, 2023

Yeah that sounds like a worse option. I'm ok with this, I'll leave it open for a bit to give people a chance to react.

@rafaqz
Copy link
Member

rafaqz commented Jun 3, 2023

Do we lose anything losing this error printing? Or things will print anyway from maybe_throw() ?

@felixcremer
Copy link
Member

If we loose the error printing, we could at least log the failure number and error message.

@visr
Copy link
Member

visr commented Jun 4, 2023

We don't lose the error printing with this. The gdaljl_errorhandler threw GDALErrors from C. This approach does not provide us with a way to clean up things on the julia side, or to customize the behavior for different functions such as IO. We already have a system in place to check for errors after a ccall. That doesn't have those limitations, and with it we actually don't need the gdaljl_errorhandler to do anything other than ignoring those calls from C.

I think the reason I kept both systems in place was because I wasn't sure if the check from the julia side would catch all the errors that the error handler catches. But I don't know any examples of that.

Another thing that I can imagine that one ccall sets first one, more informative error, and then another. In this new approach we would no longer see the first, but only the last. Though I haven't seen any examples of this either. I guess generally on CE_Failure or CE_Fatal the ccall would return anyway.

@rafaqz
Copy link
Member

rafaqz commented Jun 4, 2023

Makes sense, we can live with just the last error. Im happy with this then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants