Add util::ResultPtr class #26022
Add util::ResultPtr class #26022
Conversation
|
In draft state because it's a partial solution to #26004 and could be discussed more |
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
ryanofsky
force-pushed
the
pr/bresult-ptr
branch
from
4b8ee99
to
123788c
Compare
|
Rebased 4b8ee99 -> 123788c ( |
ryanofsky
force-pushed
the
pr/bresult-ptr
branch
from
123788c
to
a1dddc5
Compare
ryanofsky
force-pushed
the
pr/bresult-ptr
branch
from
a1dddc5
to
8ecac08
Compare
|
Rebased a1dddc5 -> 8ecac08 ( I also rewrote the commit and PR description. I think this is in a good state to review, despite being based on another PR. |
Add util::Result support for returning more error information. For better error handling, adds the ability to return a value on failure, not just a value on success. This is a key missing feature that made the result class not useful for functions like LoadChainstate() which produce different errors that need to be handled differently. This change also makes some more minor improvements: - Smaller type size. util::Result<int> is 16 bytes, and util::Result<void> is 8 bytes. Previously util::Result<int> and util::Result<void> were 72 bytes. - More documentation and tests.
Add util::Result Update method to make it possible to change the value of an existing Result object. This will be useful for functions that can return multiple error and warning messages, and want to be able to change the result value while keeping existing messages.
Add util::Result support for returning warning messages and multiple errors, not just a single error string. This provides a way for functions to report errors and warnings in a standard way, and simplifies interfaces. The functionality is unit tested here, and put to use in followup PR bitcoin#25722
Suggested by Martin Leitner-Ankerl <martin.ankerl@gmail.com> bitcoin#25722 (comment) Co-authored-by: Martin Leitner-Ankerl <martin.ankerl@gmail.com>
The util::ResultPtr class is a wrapper for util::Result providing syntax sugar to make it less awkward to use with returned pointers. Instead of needing to be deferenced twice with **result or (*result)->member, it only needs to be dereferenced once with *result or result->member. Also when it is used in a boolean context, instead of evaluating to true when there is no error and the pointer is null, it evaluates to false so it is straightforward to determine whether the result points to something. This PR is only partial a solution to bitcoin#26004 because while it makes it easier to check for null pointer values, it does not make it impossible to return a null pointer value inside a successful result. It would be possible to enforce that successful results always contain non-null pointers by using a not_null type (bitcoin#24423) in combination with ResultPtr, though.
|
Rebased 8ecac08 -> 9f58eb7 ( |
|
🐙 This pull request conflicts with the target branch and needs rebase. |
This is based on #25665. The non-base commits are:
0ff739df36c9Add util::ResultPtr class9f58eb795ec5Use ResultPtr<unique_ptr> instead of Result<unique_ptr>The
util::ResultPtrclass is a wrapper forutil::Resultproviding syntax sugar to make it less awkward to use with returned pointers. Instead of needing to be deferenced twice with**resultor(*result)->member, it only needs to be dereferenced once with*resultorresult->member. Also when it is used in a boolean context, instead of evaluating to true when there is no error and the pointer is null, it evaluates to false so it is straightforward to determine whether the result points to something.This PR is only partial a solution to #26004 because while it makes it easier to check for null pointer values, it does not make it impossible to return a null pointer value inside a successful result. It would be possible to enforce that successful results always contain non-null pointers by using a
not_nulltype (#24423) in combination withResultPtr, though.