8000 util: Make `BResult` error a generic type instead of only `bilingual_str` by w0xlt · Pull Request #25601 · bitcoin/bitcoin · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

util: Make BResult error a generic type instead of only bilingual_str #25601

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

Closed
wants to merge 8 commits into from

Conversation

w0xlt
Copy link
Contributor
@w0xlt w0xlt commented Jul 13, 2022

This PR makes BResult error a generic type instead of only bilingual_str and changes the class name to StructuredResult as BResut is not related to the purpose of the class.

The motivation is that some methods, like src/wallet/wallet.h:{RestoreWallet(...),CreateWallet(...),LoadWallet(...)} have more output parameters than just bilingual_str& error such as DatabaseStatus& status and std::vector<bilingual_str>& warnings.

With a generic template for error, it will be possible to create a struct that has bilingual_str& error and DatabaseStatus& status, for example, and use it in StructuredResult.

Built on top of #25594

@ryanofsky
Copy link
Contributor

The current BResult class is definitely very crippled, and needs to be improved to return real error handling information, not just an error reporting string.

Ironically the original implementation #25218 that had T m_result; and std::optional<bilingual_str> m_error members was not crippled, and was perfectly capable of returning rich error handling information. But after that (against all rationality!) the implementation was changed to use a std::variant so no information about the error could be returned other than the reporting string.

This PR (as of 09b796a) adds back the ability to return structured error handling information, but it loses the ability to return standard error reporting information. So it is one step forward, one step backwards, IMO.

I think a better solution is possible that:

  • adds back ability to return arbitrary data for error handling (like this PR)
  • doesn't drop the standard error reporting format, which I think we can expand and build more utilities around for more complete reporting and less boilerplate (unlike this PR)
  • doesn't require changing existing BResult usages (unlike this PR)

I had started writing up a version of this today built on #25308. Will try to post in the next few days and we can compare notes.

@ryanofsky
Copy link
Contributor

Would add I don't think iterations on the BResult class should hold up either PR #25594 or #25308. I think both PR's are in a good state and would be good to merge when they have enough review.

@DrahtBot
Copy link
Contributor
DrahtBot commented Jul 13, 2022

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #25722 (refactor: Use util::Result class for wallet loading by ryanofsky)
  • #25721 (refactor: Replace BResult with util::Result by ryanofsky)
  • #25665 (refactor: Add util::Result class and use it in LoadChainstate by ryanofsky)
  • #25616 (refactor: Return BResult from WalletLoader methods by w0xlt)
  • #25297 (wallet: speedup transactions sync, rescan and load by grouping all independent db writes on a single batched db transaction by furszy)
  • #25273 (wallet: Pass through transaction locktime and preset input sequences and scripts to CreateTransaction by achow101)
  • #24897 ([Draft / POC] Silent Payments by w0xlt)
  • #19602 (wallet: Migrate legacy wallets to descriptor wallets by achow101)

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.

w0xlt added 6 commits July 13, 2022 14:02
'BResult' is a generic class useful for wrapping
a return object o an error, but the error type is
only `bilingual_str`. This commit changes the error
for a generic type, allowing the use of this class
where the error type is not `bilingual_str`.
…Destination>

-BEGIN VERIFY SCRIPT-
sed -i 's/BResult<CTxDestination>/SingeErrorResult<CTxDestination>/g' -- $(git grep --files-with-matches 'BResult<CTxDestination>')
-END VERIFY SCRIPT-
…ransactionRef>

-BEGIN VERIFY SCRIPT-
sed -i 's/BResult<CTransactionRef>/SingeErrorResult<CTransactionRef>/g' -- $(git grep --files-with-matches 'BResult<CTransactionRef>')
-END VERIFY SCRIPT-
…Result<CreatedTransactionResult>

-BEGIN VERIFY SCRIPT-
sed -i 's/BResult<CreatedTransactionResult>/SingeErrorResult<CreatedTransactionResult>/g' -- $(git grep --files-with-matches 'BResult<CreatedTransactionResult>')
-END VERIFY SCRIPT-
…esult<std::unique_ptr<Wallet>>

-BEGIN VERIFY SCRIPT-
sed -i 's/BResult<std::unique_ptr<Wallet>>/SingeErrorResult<std::unique_ptr<Wallet>>/g' -- $(git grep --files-with-matches 'BResult<std::unique_ptr<Wallet>>')
-END VERIFY SCRIPT-
Remove `class BResult` as all references to it
were removed in the last commits.
@w0xlt
Copy link
Contributor Author
w0xlt commented Jul 13, 2022

@ryanofsky in 28c81d7, I added the class SingeErrorResult which meets all the all the requirements you mentioned:

  • adds back ability to return arbitrary data for error handling (it is a class derived from StructuredResult).
  • doesn't drop the standard error reporting format (SingeErrorResult() : StructuredResult<T, bilingual_str>(Untranslated("")) {}).
  • doesn't require changing existing BResult usages (except for the name change, this keeps the same BResult usage).

@ryanofsky
Copy link
Contributor

Thanks! Glad to see this (as of 696f953) adding back a standard type for error reporting.

I do think there are still some issues here. The main one is that I don't see a point to the StructuredResult<S, E> class. The class doesn't have any functionality, and is just a nonstandard wrapper around a std::variant<std::monostate, E, S> field. I can't imagine code that could use StructuredResult<S, E> that wouldn't be better off using std::optional<E> or std::variant<S, E1, E2, ...> avoiding the need to nest multiple error types in single error type, or call nonstandard HasRes GetObj methods, or deal with impossible null states.

Also think it would be better to standardize on an error reporting class that can return multiple errors and warnings (and optionally format the result as a single error) than a class that can only return one error. Draft PR #25608 is a little 8000 rough but starts to go in this direction.

@w0xlt
Copy link
Contributor Author
w0xlt commented Aug 3, 2022

Closing this in favor of #25721.

@w0xlt w0xlt closed this Aug 3, 2022
@bitcoin bitcoin locked and limited conversation to collaborators Aug 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0