-
Notifications
You must be signed in to change notification settings - Fork 216
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
Expose string errors from dqlite_node_create #381
Conversation
In dqlite_node_create, we no longer free the `dqlite_node *` argument and set it to NULL in the event of an error. Instead, we document that callers are responsible for calling dqlite_node_destroy even when creation fails. `struct dqlite_node` gains an additional bit of state to allow dqlite_node_destroy to gracefully handle uninitialized arguments. With these changes made, dqlite_node_create can use the errmsg channel to report human-readable errors, in line with other functions in dqlite.h (see next commit). Signed-off-by: Cole Miller <cole.miller@canonical.com>
I'll let @freeekanayaka and @MathieuBordere weight in on this one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few suggestions.
I agree with the idea of not special-casing DQLITE_NOMEM
, since it is indeed ambiguous, and the approach in the PR actually provides more details.
It seems like unnecessary coupling to use the raft constant everywhere, plus having different names makes it harder to confuse the two errmsg buffers involved. Signed-off-by: Cole Miller <cole.miller@canonical.com>
Signed-off-by: Cole Miller <cole.miller@canonical.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
@cole-miller do you expect go-dqlite to behave weirdly if I merge this? |
We'll want to update go-dqlite to revert my canonical/go-dqlite#196, but it should be okay to merge this first -- it won't change go-dqlite's externally visible behavior. |
This implements roughly @freeekanayaka's suggestion in canonical/raft#228. If we agree this is the way to go, I'll make a PR to go-dqlite to adjust its behavior accordingly.
Note that unlike Free's sample code in that thread, I don't differentiate in the public API between DQLITE_NOMEM errors and other kinds of errors. Instead, dqlite_node_errmsg and dqlite_node_destroy just handle NULL arguments gracefully. I went this route because it makes callers' lives simpler and because DQLITE_NOMEM is an ambiguous signal -- was it the
struct dqlite_node
allocation that failed, or some other allocation along the way?