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

Expose string errors from dqlite_node_create #381

Merged
merged 3 commits into from
Aug 31, 2022

Conversation

cole-miller
Copy link
Contributor

@cole-miller cole-miller commented Aug 25, 2022

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?

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>
@cole-miller cole-miller changed the title Create Expose string errors from dqlite_node_create Aug 25, 2022
@stgraber
Copy link
Contributor

I'll let @freeekanayaka and @MathieuBordere weight in on this one.

src/server.c Outdated Show resolved Hide resolved
src/server.c Outdated Show resolved Hide resolved
src/server.c Outdated Show resolved Hide resolved
src/server.c Outdated Show resolved Hide resolved
Copy link
Contributor

@freeekanayaka freeekanayaka left a 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>
Copy link
Contributor

@MathieuBordere MathieuBordere left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@MathieuBordere
Copy link
Contributor

@cole-miller do you expect go-dqlite to behave weirdly if I merge this?

@cole-miller
Copy link
Contributor Author

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.

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