Hacker News Reader

Comment by MaxBarraclough | Hacker News Reader

Yes, I suppose a simple parameter would do the job. Probably not worth anything fancy.

A parameter where? Obviously not in the code of the function itself; polluting your application code with flags such as log=true|false is obviously a no-go. Especially since logging is only one such "cross cutting concern", one of many, and you simply cannot go polluting your code with all of them because it leads to a mess.

Many Java logging systems allow you to enable/disable logging per package, but this is still not enough for a per function decision.

Logging is a hard problem.

> Many Java logging systems allow you to enable/disable logging per package, but this is still not enough for a per function decision.

I have something for that. [1]

[1] https://tersesystems.github.io/blindsight/usage/conditional....

Logging filtering is available per class in Logback [1], as well as having Markers which can target individual logging statements [2]

[1] https://stackoverflow.com/questions/46062711/show-logs-only-...

[2] https://stackoverflow.com/questions/30248169/how-to-deal-wit...

I mean there's no reason you couldn't have a thread-local override to the log level and restore it after the function call.

The fact that logging is at all intermixed with business logic I think is the main problem. I should be able to take a fully working logless program and apply different logging profiles to it. What gets logged should be a function of the person invoking the program.

Definitely. I was trying to argue something about intermixing logging with app logic :) It indeed seems to me the decision about what to log should be the caller's, not the callee's, and so it shouldn't be hardcoded within the latter.

Reply on news.ycombinator.com