[chrisguitarguy]

Log (and presumably) deal with errors if you _can deal with them_ close to where they occur. Otherwise just let them throw and/or propagate them up. An application should have some sort of top level error handling to log the error and actually return a response (HTTP 500 or otherwise) to the client.

For something like a library: no logging, that's not a library's job -- unless it's a logging library! If the language has exceptions, then throwing only subclasses or implementations of a single exception parent/interface from the entire library is nice for clients of the library.

[VBprogrammer]

Most mature languages have a logging system which allows the internal logging of a library or module to be silenced, redirected or almost any other action. I think there is a lot of value in libraries doing appropriate logging which can't easily be replicated in application code.

An example which comes to mind because I happened to be looking at it is the python Requests library where they log inform about when new connections are created / destroyed which is very useful when debugging keep-alive.

[chrisguitarguy]

> Most mature languages have a logging system which allows the internal logging of a library or module to be silenced, redirected or almost any other action. I think there is a lot of value in libraries doing appropriate logging which can't easily be replicated in application code.

Info/debug level logs sure, I don't disagree. As long as there is some built in or community standard logger and not the libraries own custom thing.

Errors, I'd rather they throw and my own app's logging facilities kick in that can provide more context: which server, which container, request info (method, path, request ID), etc. Granted some of that could come from configuring a logger with it.

[jallasprit]

I would much rather have the library expose and invoke functions which user code can hook into.