By default tinyformat errors such as 'wrong number of conversion specifiers in format string' cause an assertion failure.
Raise an exception instead so that error handling can recover or can show an appropriate error.
By default tinyformat errors such as 'wrong number of conversion specifiers in format string' cause an assertion failure.
Raise an exception instead so that error handling can recover or can show an appropriate error.
By default tinyformat errors such as 'wrong number of conversion
specifiers in format string' cause an assertion failure.
Raise an exception instead so that error handling can recover or can
show an appropriate error.
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/1b8fd35aadfad6a1e55391f02add6076c8c9ea8f for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
Do we really want to continue in case of a code typo?
It's a matter of robustness. Let's think about the following (completely imaginary) scenario:
Some rarely-hit debug logging code in the network code is using the wrong formatting. An attacker that can manage to hit this can bring down the entire node.
If we just raise a runtime exception, all it does is log and exception and kill the current connection. A nuisance instead of a DoS.
ACK from me, much better to have errors in debug.log than assertion failures.