cubranic / logr Goto Github PK

Jenny found it very surprising that message output was being let through the console despite the threshold 'console=WARN'. This happens because the system logging handler, which handles these conditions, currently:

output(s) only to logging outputs other than stderr(). The handler does not invoke any restarts, so the handling will pass on to any other active handlers up the calling chain. It is assumed that one of those will output a message to the console, if the user hasn't suppressed it.

In our last meeting, we discussed having this behaviour controlled by an additional parameter to with_logging, with the default being to handle system messages exactly the same way as regular logging messages. However, the existing behaviour could still be turned on by the caller if so desired.

Following the terminology I adopted in the vignette, messages have "levels" while destinations have "thresholds".

Mark it internal as suggested in the roxygen vignette:

Using the [@keywords internal] removes all functions in the associated .Rd file from the documentation index and disables some of their automated tests. A common use case is to both export a function (using @export) and marking it as internal. That way, advanced users can access a function that new users would be confused about if they were to see it in the index.

Log4j, and on the R side futile.logger and log4r (but not logging), distinguish between FATAL and ERROR messages. Here is one description:

• FATAL: very severe error events that will presumably lead the application to abort.
• ERROR: error events that might still allow the application to continue running

See https://github.com/craigcitro/r-travis/ for instructions.

URL: https://github.com/cubranic/logr

Level-specific message functions have the ... argument that's intended to be passed through to add_log, but currently isn't

I have formatted some text where the whitespace is very important. When I log via warn(), it oversteps its mandate and edits (mostly deletes) the whitespace.

Example:

d> warn(c("0: foo", "1:         yo"))
0: foo
1: yo

Same goes for error(), info(), debug(), and trace(), so I'm blaming logr().

Calling stop from within the expr argument to with_logging outputs an error message that's confusing and unnecessarily reveals internals of with_logging:

> with_logging(stop('foo'))
Error in withCallingHandlers(expr, LoggingMessage = make_logging_handler(log_outputs),  (from logging.R#51) : 
  foo

Instead, we should probably use the call to with_logging as the reported location of the error instead of withCallingHandlers.

(First reported in jennybc/fh2#31)

Currently, add_log detects when no active loggers are present and in that case uses message to output it regardless of the level. It could be a little smarter and do different things depending on the log message level. For instance, if ERROR were output with stop, WARN with warning, and INFO with message, while DEBUG and TRACE were not output at all, we would have a sensible out-of-the-box default behaviour even if the user does not bother to run the code within with_logging.

error_log currently does not stop execution of the program, and so would usually need to be followed by stop if that's desired. Do we want to change this?

logr::debug() masks the base function debug(), which might be a really bad idea.