4 ms·
Error-handling code is definitely poorly-tested in my experience across many code bases. Although printf()-style logging has advantages, a huge disadvantage is
by makecheck 8y ago
Error-handling code is definitely poorly-tested in my experience across many code bases. Although printf()-style logging has advantages, a huge disadvantage is that it tends to be the reason error-handling code fails: something meant to write a simple log message gets the format/type wrong and an error condition turns into a crash or obscure corruption. In fact, logging code that was once correct can become wrong if the target variable type changes. This is why I love Python format-strings with “{}”, a.k.a. the “just do the right thing here” syntax.
Generally the advice of “pick a few failure types and stick to them” is exactly right. You not only encourage error handling to take place but that code is likely to remain correct/complete over time.
- ben-schaaf 8y agoAn issue that can still happen with python's string formatting is that you can get the number of arguments/`{}` wrong. D (other languages too, probably) has compile-time format string, as well as automatic string conversion: `format!"%s"(2)`. Giving the wrong format string/argument types fails at compile time. Some C/C++ compilers also automatically check this for printf. Though they can still fail if the actual output writing fails, ie. stdout is closed or doesn't exist.
- teddyh 8y ago> An issue that can still happen with python's string formatting is that you can get the number of arguments/`{}` wrong. Easily avoided by using the latest Python feature, added in 3.6: Formatted string literals, a.k.a. f-strings¹. Instead of using "foo {} baz".format(bar) you use f"foo {bar} baz" 1. https://www.python.org/dev/peps/pep-0498 https://www.python.org/dev/peps/pep-0498
- thrower123 8y agoThis is one of the reasons I love the newer C# string interpolation feature. No more frigging string.Format() strings with positional arguments.