On 2016-07-08 20:28, Konstantin Khomoutov wrote:
I think I understand your concerns, and actually has nothing to say
against them. The only possible (and very real) case is that easy to
use full-blown logging tends to be abused in some circles, namely, in
the Java world where every freaking JAR depends on log4j or something
like this for no reason. But this topic has already been rehashed
several times on this list (the consensus was, IIRC, that no library
code has a luxury of using direct logging and has to expose some sort
of callback-enabled code so that the user's main() could make use of
its logging abilities when needed).
Yeah... I tend to avoid logging in libraries where ever possible.
... and instead return errors, preferable wrapped like with
github.com/pkg/errors
[*] If I would be designing the standard "log" package I'd made all
Print*() function log to stdout and would have a matching set of
Error*() functions which would log to stderr.
Hmm... Not sure I see the use case for this.
I don't get why "log" streams everything to stderr:
You can change that.
Unix has two
distinct standard output streams since forever precisely to be able to
direct "normal" output to stdout and warnings/errors to stderr.
Sure... but most log libraries (including stdlib) lets you define more
loggers if you need both.
This provides for two use-cases:
1) One can silence just the normal output or just the error output,
if needed, which is sometimes useful for scripting.
You can do that with more *log.Logger (or similar in almost every log
library I've seen)
2) Daemon supervision software such as daemon(1) or systemd usually
have the nice property of being able to channel what your program
being supervised outputs to its standard streams to the syslog
(or other system-wide logging subsystem), and it uses the nature of
the stream (stdout vs stderr) to mark the information as "nofices"
or "errors", respectively.
That's one of the reasons I wrote github.com/One-com/gonelog
/Peter
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
