Hacker News Reader

Comment by paulddraper | Hacker News Reader

(1) I see this all the time.

An error is logged and propogated, then logged and propogated, then logged and propogated, then pretty soon your logs are 50x copies of themselves and the flood of logging sweeps you away.

You either (a) know what you to do about an error and log it or (b) you don't know what to do and propogate it.

An error should be logged eventually, but it shouldn't be logged 20 times.

View on HN

I totally agree, there's no need to log that you bubbled an error. My recommendation is to have the function that generates the error also log it internally. That way, you don't need to log any returned errors at all, unless you are calling a 3rd party library that can't log it's own error.

Error handling, which includes logging the error, should almost always be the responsibility of the caller. Only the caller knows why the call was made, and only the caller knows the impact of the error on what the caller is trying to do.

Exactly.

You run a process that exits with a non-zero code. Is that an error that should be logged? Or just informational? (E.g. `diff`.)

You request an HTTP resource that doesn't exist. Loggable error? Or normal result?

Only the caller knows.

I recommend separating collection from instrumentation. Always instrument at the source, so that you can instrument the flow of your entire application. If the caller decides there is something about the code flow that is worth recording, it can trigger collection of the entire trace.

I see that way too often. Bonus points if the exceptions are being logged in different ways, in different parts of the library.

Reply on news.ycombinator.com