3 ms·
> Log after, not before This is already weird, what about operations that take a long time? If the session is interactive, the user should definitely know that
by rhn_mk1 5y ago
> Log after, not before
This is already weird, what about operations that take a long time? If the session is interactive, the user should definitely know that nothing hung up. Or is it out of scope somehow?
- namanyayg 5y agoYeah, it's best to log BOTH before and after.
- stinos 5y agoOr if you think both is too much, probably only before? Might depend on te application but I've seen enough native application logfiles with "did FOO" as very last line meaning the crash happened on the action executed next, but that wasn't logged because 'log after!'...
- rhn_mk1 5y agoLogging before has the disadvantage of being noisier than after only, at least if you want to inspect the result of the operation.
- piaste 5y agoI tend to use VERBOSE severity if I'm just logging "we've reached this line in the code and local variables are set to $whatever". Since you generally only want to see them when diagnosing a frozen job or something equally obtuse.
- raldi 5y agoThe author later explains that in such situations, you log before at DEBUG level, and after at INFO.
- SideburnsOfDoom 5y agoFor that there is is usually some log wrapper that times the operation, e.g. using(_log.TimeOperation("Doing the thing")) { DoTheThing(); } So that you get a start message, and an end message with timing, and if you exited with normal control flow vs. with an exception. Author doesn't seem to have reached that level of best practice yet.