[
https://issues.apache.org/jira/browse/LOG4J2-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17243718#comment-17243718
]
Ralph Goers commented on LOG4J2-2970:
-------------------------------------
While this is a good idea implementing this would break compatibility with
existing implementations of the Log4j API. Furthermore, if logging is not
enabled for that logger the string would never be created to be returned.
I just don't see how this can be implemented.
> Adding String return type of each log method
> --------------------------------------------
>
> Key: LOG4J2-2970
> URL: https://issues.apache.org/jira/browse/LOG4J2-2970
> Project: Log4j 2
> Issue Type: New Feature
> Components: API
> Affects Versions: 2.13.3
> Reporter: Colin Zhang
> Priority: Critical
> Labels: API, user-experience
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> In many industry systems, we need to log the error and then throw a new
> exception with the same message. The logger will populate the message with
> markers and variables.
> But we need to manually populated it by string + again when construct the
> exception message. This is an anti-pattern.
> Please take below snippet as example:
> {code:java}
> log.error("The number of records is {} which exceed the threshold {}", num,
> threshold);
> throw new ValidationException("The number of record is " + num + " which
> exceed the threshold " + threshold);
> {code}
>
> If the API can return populated message, the code would turn much better:
> {code:java}
> String error = log.error("The number of records is {} which exceed the
> threshold {}", num, threshold);
> throw new ValidationException(error);
> {code}
>
> The only concern is that this may only works for synchronous logging, not
> work for asynchronous way. But I believe it could be resolved.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
