kernel: Handle fatal errors through return values #29642
Commits on Mar 26, 2024
-
refactor: Drop util::Result operator=
In cases where different error conditions need to be handled differently, it is useful for `util::`Result` objects to be able to hold failure values and error messages simultaneously. Also it is useful for `util::Result` objects to be able to hold multiple error message strings and warnings, instead of just single error strings. In both of these cases, which are supported in upcoming commits, having an `operator=` method is potentially dangerous if it clears existing error and warnings strings while setting result values, or confusing if it doesn't clear them, so the safest thing is to disable `operator=` and provide an explicit `Set()` method so callers have a way of setting result values without having to clear message strings.
-
refactor: Avoid copying util::Result values
Copying util::Result values is less efficient than moving them because they allocate memory and contain strings. Also this is needed to avoid compile errors in the next commit which adds a std::unique_ptr member to util::Result which implicity disables copying.
-
refactor: Add util::Result failure values
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.
-
refactor: Add util::Result multiple error and warning 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
-
test: add static test for util::Result memory usage
Suggested by Martin Leitner-Ankerl <martin.ankerl@gmail.com> bitcoin#25722 (comment) Co-authored-by: Martin Leitner-Ankerl <martin.ankerl@gmail.com>
-
Add bitcoin-fatal-error clang-tidy check
The check warns about incorrect usage of util::Result<T, FatalError>. The check enforces the following rules: 1. If a function calls another function with a util::Result<T, FatalCondition> return type, its return type has to be util::Result<T, FatalCondition> too, or it has to handle the value returned by the function with one of "CheckFatal", "HandleFatalError", "UnwrapFatalError", "CheckFatalFailure". 2. In functions returning a util::Result<T, FatalCondition> a call to a function returning a util::Result<T, FatalCondition> needs to propagate the value by either: a) Returning it immediately b) Assigning it immediately to an existing result with .MoveMessages() or .Set() c) Eventually passing it as an arugment to a .MoveMessages() call -
kernel: Handle ImportBlocks fatal errors with Result<T, FatalError>
This introduces a new FatalError enum class whose semantics when used as a failure type in a util::Result<T, FatalError> are controlled by the previously introduced bitcoin-fatal-error clang-tidy plugin. The kernel's `UnwrapFatalError` method is meant to be used in unit and fuzz tests, while production code should use `CheckFatal` to handle fatal errors.
-
-
-
kernel: Handle ValidatedSnapshotCleanup fatal errors with Result<T, F…
…atalError> This slightly refactors the method to return the FatalError instead of throwing.
-
kernel: Handle MaybeCompleteSnapshotValidation fatal errors with Resu…
…lt<T, FatalError>
-
kernel: Handle AcceptBlock fatal errors with Result<T, FatalError>
To propagate the FatalError, also add the type to InvalidateCoinsDBOnDisk and AcceptBlock. The net_processing module now has to handle a FatalError, so introduce shutdown and exit_status member variables for to be able to abort.
-
kernel: Handle ActivateBestChainStep fatal errors with Result<T, Fata…
…lError> To propagate the FatalError, also add the type to PreciousBlock and ActivateBestChain.
-
kernel: Handle FlushStateToDisk fatal errors with Result<T, FatalError>
To propagate the FatalError, also add the type to PruneBlockFilesManual, AcceptToMemoryPool, ProcessNewPackage, ResizeCoinsCaches, ForceFlushStateToDisk, PruneAndFlush, DisconnectTip, InvalidateBlock, MaybeUpdateMempoolForReorg, ProcessTransaction, MaybeRebalanceCaches, LoadMempool
-
kernel: Handle ConnectBlock fatal errors with Result<T, FatalError>
To propagate the FatalError, also add the type to VerifyDB and TestBlockValidity. The miner module now has to handle a FatalError, so introduce shutdown and exit_status member variables for it to be able to abort.
-
kernel: Handle SaveBlockToDisk fatal errors with Result<T, FatalError>
To propagate the FatalError, also add the type to LoadGenesisBlock.
-
kernel: Handle FlushBlockFile fatal errors with Result<T, FatalError>
To propagate the FatalError, also add the type to FlushChainstateBlockFile.
-
kernel: Handle LoadBlockIndex fatal errors with Result<T, FatalError>
To propagate the FatalError, also add the type to LoadBlockIndexDB.
-
Remove flushError, fatalError from kernel notifications
Also add using declarations where now possible.
