[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