[slf4j-dev] [JIRA] (SLF4J-490) Better combination for logging and exceptions
QOS.CH (JIRA)
noreply-jira at qos.ch
Thu May 7 01:12:00 CEST 2020
Norbert Kiesel created SLF4J-490:
------------------------------------
Summary: Better combination for logging and exceptions
Key: SLF4J-490
URL: https://jira.qos.ch/browse/SLF4J-490
Project: SLF4J
Issue Type: Improvement
Components: Core API
Affects Versions: 1.7.29
Reporter: Norbert Kiesel
Assignee: SLF4J developers list
Hi,
we have quite a few places in our code where we do:
{code:java}
logger.error("Param {} must be in [{}-{}]", name, low, high);
throw new ValidationException("Param " + name + " must be in [" + low + "-" + high + "]"); {code}
This is obviously ugly. Other options would be to use
{code:java}
String msg = String.format("Param %s must be in [%s-%s]", name, low, high);
logger.error(msg);
throw new ValidationException(msg);{code}
or
{code:java}
String msg = MessageFormatter.format("Param {} must be in [{}-{}]", new Object[] {name, low, high}).getMessage();
logger.error(msg);
throw new ValidationException(msg); {code}
Both are not ideal. Can't we have a `Logger.format` method which returns a `FormattingTuple` w/o the explicit array creation
and allow `Logger.error` etc. to be called with a `FormattingTuple`? Then I could write
{code:java}
FormattingTuple entry = logger.format("Param {} must be in [{}-{}]", name, low, high);
logger.error(entry);
throw new ValidationException(entry.getMessage());{code}
For my own exception classes I could then even offer a constructor that takes a FormattingTuple and internally use the message and the throwable (if it is not null).
Bonus: pick a nicer name than `FormattingTuple` like `LogEntry`.
--
This message was sent by Atlassian Jira
(v8.8.0#808000)
More information about the slf4j-dev
mailing list