-
Notifications
You must be signed in to change notification settings - Fork 42
Check libcurl return value #138
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
base: main
Are you sure you want to change the base?
Conversation
fca51f5 to
3e98332
Compare
|
I think first point is valid, unsure if it should be a D_ASSERT (meaning only there on relassert) or then a throw of some kind (unsure which), so that is visible to all users. Second split-off PR has already been merged. Third I guess so. |
The reason I use check failure here is: we're simply setting configs for curl handle, and they're not expected to fail. |
|
Current implementation is actually buggy:
|
The motivation comes from duckdb/duckdb-httpfs#138 where I do want to validate against all curl-related functions' return value to act as sanity check and shall never fail, not only for debug build, but also for release build. One thing I feel painful when I was writing extension, more often than not, I wrote statements like ```cpp D_ASSERT(do_something_and_return()); ``` which gets skipped in release build :( This PR adds a new assertion macro, which always triggers whatever build type it is, to act as a sanity check.
This PR does two things:
duckdbnamespace