-
Notifications
You must be signed in to change notification settings - Fork 13
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
Relax null checking for certain methods #19
Comments
Perhaps the "certain methods" is best decided by GDAL itself? If we remove I checked a few examples after setting These examples seem reasonable, do you think we should just remove |
I think
The alternative is to let users handle it for themselves, which is equivalent to not addressing the problem at a library-level. For now, I don't have a good understanding of how everything works with CPLErrors yet, and propose we come up with a list of methods for which
And update them as we go? I'll go ahead and prepare the lists based on what I've seen in GDALUtils if we have a consensus here. I'm afraid I've reached the end of my spring break and won't have time to do a more systematic/comprehensive sweep of all the methods for now. Waiting on responses from @visr @meggart, and whoever wishes to chime in! |
I don't have a very strong opinion on this one, but I tend to think we should rather remove checknull and leave the null checking to the user to avoid unnecessary try-catch blocks, which might have negative performance effect. As @visr said, if GDAL decides not to throw an error, we also shouldn't do this. However, if we can come up with a good list of where nullchecks make sense and where they don't and adapt the functions accordingly, that's ok, too but probably more work. |
I was originally reluctant about nullchecks in #3 (comment), but have since changed my mind after reading a lot of GDAL usage code out in the wild (they tend to result in a ton of boilerplate code). Coming up with a good list where nullchecks make sense etc is more work; but it is worthwhile work, and has the most benefit when it's close to the rewriting process after code-generation from Clang. This package currently provides both options:
Some remarks:
If we let this package check null pointers by default, then it becomes a lot easier to surface 10% of the methods for which "C_NULL != error" (through usage and experience). If we switch off nullchecks, then we are stuck with the status quo of letting the users perform it for 90% of the methods (and downstream packages will individually still have to perform the task of identifying which methods to check null). I have been working on GDALUtils to fuzz out most patterns of usage, so the remaining surface area should be diminishingly small, and makes it quite compelling for this package to check null pointers by default. |
Pinging @rouault if he has feedback. For context: this package is a volunteer-based effort to provide a thin wrapper for GDAL usage in the Julia programming language, where we
We are wondering if there might be list(s) of methods for which
and (if not) whether it might be possible to generate such list(s) from the gdal trunk. |
Relevant reading for ongoing art:
pinging @sgillies @perrygeo @brendan-ward for comments/feedback |
I'll maintain an ongoing list of references here for now: |
Not sure to understand the question. OGRErr is a type, used as the returned value of functions, which you can check in the signatures, so not something "emitted".
CPLError() can be called whether the return code of the function is successful or not, but I'd suggest that you can check with CPLGetLastErrorXXXX() when the return code is an error (or if you check always, do not error out if the error type was just a warning for example)
Do you mean if a NULL pointer as the return of a function should be interpreted as an error ? That depends on the context. If a pointer is returned, and it is NULL, I would check CPLGetLastErrorType() == CE_Failure to determine if an exception (or whatever the mechanism is in Julia) must be thrown or not |
I should have reworded "emitted" to "returned" for clarity.
I think that cleared up my confusion, thanks! |
Fixes #19 Now a GDALError is only thrown in `checknull` if both the pointer is null and the last error type is either CE_Failure or CE_Fatal, as suggested by Even Rouault. The error handler that we register is given the same behavior (throw on failure & fatal), instead of previously always raising an error when called. At the same time this restructures and tests the error handling a bit better.
Fixes #19 Now a GDALError is only thrown in `checknull` if both the pointer is null and the last error type is either CE_Failure or CE_Fatal, as suggested by Even Rouault. The error handler that we register is given the same behavior (throw on failure & fatal), instead of previously always raising an error when called. At the same time this restructures and tests the error handling a bit better.
Fixes #19 Now a GDALError is only thrown in `checknull` if both the pointer is null and the last error type is either CE_Failure or CE_Fatal, as suggested by Even Rouault. The error handler that we register is given the same behavior (throw on failure & fatal), instead of previously always raising an error when called. At the same time this restructures and tests the error handling a bit better.
I'm not sure if null checking should be performed (forcing downstream packages/users to wrap everything in a try-catch block) for cases in which you are expecting a null pointer to be returned. Case in point: https://github.com/visr/GDAL.jl/blob/master/src/ogr_api.jl#L3997-L4010
This came up when I was writing iterators for OGR feature layers, e.g. https://github.com/yeesian/GDALUtils.jl/blob/master/test/data1a.jl#L7-L13. I ended up using the C API instead: https://github.com/yeesian/GDALUtils.jl/blob/master/src/iteration.jl#L7-L8.
cc @visr @meggart
The text was updated successfully, but these errors were encountered: