[ 
https://issues.apache.org/jira/browse/LOG4J2-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17243720#comment-17243720
 ] 

Colin Zhang commented on LOG4J2-2970:
-------------------------------------

Hi [~rgoers],

Thanks for your quick response. I believe in modern system, over 99% time, the 
logging in enabled. And this is only disabled for DRY RUN, and if it is a DRY 
RUN,  leave error message as empty or return the marker without population 
would not be a problem for most of cases.

Anyway, please consider the scenario I mentioned. As far as I can see,  most of 
time,  the code are like that in many of companies' industry code.

> 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)

Reply via email to