On Monday, 21 October 2013 at 06:27:39 UTC, SomeDude wrote:
On Thursday, 17 October 2013 at 07:34:28 UTC, qznc wrote:
On Thursday, 17 October 2013 at 02:13:12 UTC, Eric Anderton
wrote:
The strength of this is that it would allow us to freely
integrate D libraries that use std.logger, yet filter their
log output from *outside* the library through the std.logger
API.
This is one of the most important aspects in my opinion.
Std.logger should be easy to use, so library writers are
encouraged to use it. Compare this with the "unittest" keyword,
which makes it easy to write some simple tests. Of course,
flexibility to use complex machinery for using the
messages/tests
is necessary. Just like we can hook up more advanced unit
testing
frameworks, we should be able to hook up more advanced logging
machinery. The advanced stuff is not for Phobos though.
Advanced
stuff for unittests is for example, parallel execution and
graphical reports. Advanced stuff for logging is for example
log
rotation and networking.
There is no contradiction. Complex log libraries become
(relatively) complex when one wants to use their advanced
features, but are as simple as the others when one wants to use
them simply.
That's why in the Java world nearly everyone uses Log4j instead
of the official JEE API.
In practive, you really want a powerful logging facility.
Another feature I used once in a project, was to log to RAM. We
decided to log TRACE logs in production in order to catch a
rare bug, but of course, it would output too many logs. So we
decided to log everything in RAM and keep the last 1000 logs.
Whenever there would be an exception or a CRITICAL log, the
whole 1000 logs would be dumped on disk. That feature proved
very useful.
+1
Also, it would be useful to use buffered asynchronous logger
(mentioned above).
It will help to trace and save all logs, but should be fast for
production usage.
