Timeline for TL suggests that testing, refactor, and tool usage could avoid the need for verbose logging
Current License: CC BY-SA 4.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 6, 2022 at 8:47 | comment | added | Flater | In other words, you only really need to log what happens at the boundary between the unmanaged (end users, external systems) and your codebase. Within your codebase, you shouldn't be relying on runtime logging to make sense of your code, because that means you've written code that does not make sense and has not been vetted yet. | |
| May 6, 2022 at 8:45 | comment | added | Flater | Verbose logging of most method calls in a chain is a somewhat different beast though. Generally speaking, logging the entry point (e.g. API endpoint and input values) and any thrown exceptions suffices for debugging purposes. A properly unit tested codebase would already catch most issues in specific components, the exception log reveals that there is an uncaught issue, and the entry point log provides the needed information to debug and home in on the uncaught issue. When caught, the unit tests should be updated to account for the now caught issue (when relevant). | |
| May 6, 2022 at 2:19 | history | answered | mmathis | CC BY-SA 4.0 |