tryCatchLog suppression settings for each condition type

In #44 you asked an open question about whether there should be a matrix configuration to supress the trace specifically by condition type. This would be great in scripts where messages are used for informational purposes and should not require an entire trace, while an error or warning may indeed require the trace to be there. This was not added when #44 was closed as far as I can tell. Is there a workaround perhaps? Otherwise it would be a great feature.

Dec 12 '21 10:12 nickdickinson

I guess you are referring to this open question I have documented in #44 for myself:

Open questions:

Does it make sense to allow different suppression settings for each condition type (error, warning, message...)? This would span a configuration "matrix".

I did not implement this together with #44 since I had no real use case for this and nobody has asked for this so far (which has obviously changed now ;-)

Another pending decision was whether tryCatchLog should suppress the stack trace in the log output or whether this should better be done at the logging framework side.

Possible work-arounds

In the logging framework

Since the log message (incl. the compact or full stack trace) is created in my code (https://github.com/aryoda/tryCatchLog/blob/master/R/tryCatchLog.R#L299) the logging framework cannot "undo" this easily.

At the logging framework side I could imagine two "dirty" work-arounds:

Write only the first n lines to the output by using a custom logging function instead of the default one for the desired severity level(s) and enable it via tryCatchLog::set.logging.functions(), e. g. when using my internal logging functions via:

library(tryCatchLog)

options(tryCatchLog.include.full.call.stack = FALSE)
tryLog(log(-1))  # shows the compact call stack
# tryCatchLog::set.logging.functions(warn.log.func = function(msg) tryCatchLog:::log2console("WARN", substr(msg, 1, 20))) # show only the first n chars
tryCatchLog::set.logging.functions(warn.log.func = function(msg) tryCatchLog:::log2console("WARN", head(unlist(strsplit(msg, "\n", fixed = TRUE)), 1)))
tryLog(log(-1)) # shows only the first line

Write the log output to different files (one file per severity level).

You can use the logging level as filter to write to different files (looks complicated but has the advantage of always seeing all logged messages of the same or higher log levels in one file...):

library(futile.logger)
library(tryCatchLog)

options(tryCatchLog.include.full.call.stack = FALSE)
tryLog(log(-1))  # shows the compact call stack
# Set an appender to a file named using the severity level (ERROR.log, WARN.log, INFO.log) applied for filtering:
# Each file contains ALL logging output of the according or higher log levels!
flog.appender(appender.file2('~l.log', console = TRUE)) # ~l = log level (see ?futile.logger::flog.layout)
tryLog(message("just an info")) # only logged in INFO.log
tryLog(log(-1)) # not logged in ERROR.log
tryLog(log("a")) # this error is logged in ERROR.log, WARN.log and INFO.log

None of the above work-arounds is nice or perfect :-(

In `tryCatchLog`

This requires code changes and I think there is no easy work-around for end users of tryCatchLog for now.

Next steps

Please give me some time to think about your feature request and how it could be implemented easily (incl. ease-of-use for end users). I don't want to make it too complicated for the end user though offer the possibility for customization...

I also want to re-think about another feature request in this context: Supressing selected ("hand-picked") conditions - see eg. #11

Any proposals are welcome :-)

Dec 12 '21 13:12 aryoda

So I can see that #11 is a challenge fundamentally. But perhaps first education of package developers to follow patterns that will help us differentiate conditions.

For this one, you might consider the following for a form of configuration. I still need to consider your work arounds and look through the code but I might have some ideas for tryCatchLog.

options(test_option = list(warning = c(include.full.stack = FALSE, include.compact.stack = TRUE), message = c(include.full.stack = FALSE, include.compact.stack = FALSE), my_custom_condition = c(include.full.stack = TRUE, include.compact.stack = FALSE)))

getOption("test_option")$warning["include.full.stack"]

getOption("test_option")$my_custom_condition["include.full.stack"]

Dec 13 '21 20:12 nickdickinson

So after having a think and looking at the code, I think the easiest for the end user would be to have a way to configure existing and new conditions with a simple function rather than directly in options.

I would think the severity level would be configurable and also the tryCatchLog package would have a way to register new user created conditions. One can then presumably use the registered conditions, rather than the static character strings ("warning", "error", etc.) to test for inheritance. Would this be feasible? The user does not have to know too much about how to build options and you could still leave the include.full.stack in the arguments for backward compatibility.

It might look like this:

In package code (to replicate current behavior) on load:

conditionLogOption("message", severity = "INFO") 
conditionLogOption("warning", severity = "WARN") 
conditionLogOption("error", severity = "ERROR") 
conditionLogOption("condition", severity = "INFO")

In user code, to modify behavior:

conditionLogOption("message", include.full.stack = FALSE, include.compact.stack = FALSE) 
conditionLogOption("my_custom_warning_condition", include.full.stack = FALSE, include.compact.stack = TRUE, severity = "WARN")

The option might be saved in a format such as in my prior message to store the condition names and behaviors. Of course, this pattern would open up possibilities to do other interesting customizations based on conditions where the user can let, for example, the tryCatchLog know if for example attributes are ok on conditions (for duplicate checking). One might even be able to start to deal with #11 in a more systematic way if this would be become a wider used pattern upstream. But that is all out of scope. Interested in hearing if you think this may be feasible. I think it would require some minimal refactoring of the current tryCatchLog function....