3 ms·
> Log after, not before I tried this recently by accident, and the drawback of that approach immediately became apparent: The logs will be very difficult to r
by nh2 5y ago
> Log after, not before
I tried this recently by accident, and the drawback of that approach immediately became apparent:
The logs will be very difficult to read, because for nested function calls, low-level callee functions will log before high-level caller functions, and you have no idea why they are called until later:
Finished string comparison of length 4
... 200 more lines...
Finished string comparison of length 2
Finished Boyer-Moore string search
Finished searching for example.com
Finished searching for disallowed domains
Finished checking email address
Finished logging in user
With the suggested approach, you'll have to read your logs backwards to make sense of them.
- shkkmo 5y agoThere's nothing wrong with reading logs backwards and it is arguably better because (when testing or diagnosing exceptions) finding the end of the log is generally quicker than finding the point midway through the log where your task ran. There's nothing stopping you from adding "Begin User Login" logging calls if you want to make the nesting more explicit. If you no idea why stuff is being called, it's only because you have unlogged branches in your code. and it is way better than reporting success when it hasn't actually happened.
- sagichmal 5y agoYou only emit a single log event (line) per request. Problem solved.