@ -723,6 +723,47 @@ General Bitcoin Core
- *Explanation* : If the test suite is to be updated for a change, this has to
- *Explanation* : If the test suite is to be updated for a change, this has to
be done first.
be done first.
Logging
-------
The macros `LogInfo` , `LogDebug` , `LogTrace` , `LogWarning` and `LogError` are available for
logging messages. They should be used as follows:
- `LogDebug(BCLog::CATEGORY, fmt, params...)` is what you want
most of the time, and it should be used for log messages that are
useful for debugging and can reasonably be enabled on a production
system (that has sufficient free storage space). They will be logged
if the program is started with `-debug=category` or `-debug=1` .
Note that `LogPrint(BCLog::CATEGORY, fmt, params...)` is a deprecated
alias for `LogDebug` .
- `LogInfo(fmt, params...)` should only be used rarely, eg for startup
messages or for infrequent and important events such as a new block tip
being found or a new outbound connection being made. These log messages
are unconditional so care must be taken that they can't be used by an
attacker to fill up storage. Note that `LogPrintf(fmt, params...)` is
a deprecated alias for `LogInfo` .
- `LogError(fmt, params...)` should be used in place of `LogInfo` for
severe problems that require the node (or a subsystem) to shut down
entirely (eg, insufficient storage space).
- `LogWarning(fmt, params...)` should be used in place of `LogInfo` for
severe problems that the node admin should address, but are not
severe enough to warrant shutting down the node (eg, system time
appears to be wrong, unknown soft fork appears to have activated).
- `LogTrace(BCLog::CATEGORY, fmt, params...) should be used in place of
`LogDebug` for log messages that would be unusable on a production
system, eg due to being too noisy in normal use, or too resource
intensive to process. These will be logged if the startup
options `-debug=category -loglevel=category:trace` or `-debug=1
-loglevel=trace` are selected.
Note that the format strings and parameters of `LogDebug` and `LogTrace`
are only evaluated if the logging category is enabled, so you must be
careful to avoid side-effects in those expressions.
Wallet
Wallet
-------
-------
@ -891,7 +932,7 @@ Strings and formatting
`wcstoll` , `wcstombs` , `wcstoul` , `wcstoull` , `wcstoumax` , `wcswidth` ,
`wcstoll` , `wcstombs` , `wcstoul` , `wcstoull` , `wcstoumax` , `wcswidth` ,
`wcsxfrm` , `wctob` , `wctomb` , `wctrans` , `wctype` , `wcwidth` , `wprintf`
`wcsxfrm` , `wctob` , `wctomb` , `wctrans` , `wctype` , `wcwidth` , `wprintf`
- For `strprintf` , `Log Print`, `LogPrintf` formatting characters don't need size specifiers.
- For `strprintf` , `Log Info`, `LogDebug` , etc formatting characters don't need size specifiers.
- *Rationale* : Bitcoin Core uses tinyformat, which is type safe. Leave them out to avoid confusion.
- *Rationale* : Bitcoin Core uses tinyformat, which is type safe. Leave them out to avoid confusion.
@ -903,7 +944,7 @@ Strings and formatting
- *Rationale* : Although this is guaranteed to be safe starting with C++11, `.data()` communicates the intent better.
- *Rationale* : Although this is guaranteed to be safe starting with C++11, `.data()` communicates the intent better.
- Do not use it when passing strings to `tfm::format` , `strprintf` , `Log Print[f]` .
- Do not use it when passing strings to `tfm::format` , `strprintf` , `Log Info`, `LogDebug` , etc .
- *Rationale* : This is redundant. Tinyformat handles strings.
- *Rationale* : This is redundant. Tinyformat handles strings.