4 ms·

> the exception should be able to tell you that you failed on the line _before_ the "log after". It is an extension of the «but it worked on my laptop» mentali

> the exception should be able to tell you that you failed on the line _before_ the "log after". It is an extension of the «but it worked on my laptop» mentality. No, it won't work in a complex environment, specifically in a scenario where a server farm sits behind a load balancer with a VIP (geographically distributed or not), which is ubiquitous. Specifically, it won't work in a situation where a server instance the application attempted to connect to sits in a subnet in another data centre across a WAN link, and the networks put a shoddy firewall rule in last night or applied a bit rotten firmware patch to the router, and new server connections suddenly started getting TCP resets halfway through the data exchange. You won't know which particular service instance the resolver ended up resolving and connecting to unless you have a "before" log entry as well. Hiding the dead horse in the cloud will help in a serverless or in a simple scenario, but, if you have a load balancer and multiple availability zones, you still have the same problem, due to cloud load balancers failing over to another AZ at will (it is more nuanced than that, though). Logging inputs is as critically important as logging preceding statement's outcome, albeit it has to be used wisely as excessive and, worse, not properly structured log entries can (and will) overwhelm the log sink in a high data volume environment. Log ring buffers can be a solution for some cases, and a monitoring component that is integrated into an app can be an answer in some other cases, but there is no single, one size fits it all, solution for an arbitrary setup in a high data volume environment.

SideburnsOfDoom 5y ago
In the apis that I am familiar with, there is typically generic, cross-cutting logging as a filter on all http requests, so you always log the "GET on /customers/123". This is a given, it's typically done by "add the library, one line of code at startup to enable it" While this technically qualifies as "Logging inputs before" it does not seem to be what the author is talking about. I was assuming that was present, and had been reached - cause if it had not, what request are you even debugging? Rather than some "«but it worked on my laptop» mentality" straw man.

SideburnsOfDoom 5y ago

In the apis that I am familiar with, there is typically generic, cross-cutting logging as a filter on all http requests, so you always log the "GET on /customers/123". This is a given, it's typically done by "add the library, one line of code at startup to enable it" While this technically qualifies as "Logging inputs before" it does not seem to be what the author is talking about. I was assuming that was present, and had been reached - cause if it had not, what request are you even debugging? Rather than some "«but it worked on my laptop» mentality" straw man.