When I started to read this I thought the conclusion was going to end with  
something more like:

throw new ValidationException(logger.error("Param %s must be in [%s-%s]", name, 
low, high));

Or 

logger.throw("Param %s must be in [%s-%s]", name, low, high), 
ValidationException.class);

But I don’t see the point of trading

String msg = String.format("Param %s must be in [%s-%s]", name, low, high);
logger.error(msg);
throw new ValidationException(msg);

for

FormattingTuple entry = logger.format("Param {} must be in [{}-{}]”, name, low, 
high);
logger.error(entry);
throw new ValidationException(entry.getMessage()); 

This is just trading one set of 3 lines of code for another.

Ralph



> On May 6, 2020, at 4:58 PM, Robert Middleton <osfan6...@gmail.com> wrote:
> 
> This would result in a large number of methods to be added most
> likely, but you could potentially combine the logging with the
> exception throwing:
> 
> logger.errorAndThrow( message, ValidationException.class );
> 
> which would log the message at the error level, and then use the given
> class to construct the exception and throw it.
> 
> -Robert Middleton
> 
> On Wed, May 6, 2020 at 3:43 PM Matt Sicker <boa...@gmail.com> wrote:
>> 
>> Potentially useful API update to look at here. Some sort of Logger that
>> throws an exception with the log message instead?
>> 
>> ---------- Forwarded message ---------
>> From: Norbert Kiesel <nkie...@metricstream.com>
>> Date: Wed, 6 May 2020 at 12:59
>> Subject: [slf4j-user] Combined logging and throwing question
>> To: User list for the slf4j project <slf4j-u...@qos.ch>
>> 
>> 
>> Hi,
>> 
>> we have quite a few places in our code where we do:
>> 
>>    logger.error("Param {} must be in [{}-{}]", name, low, high);
>>    throw new ValidationException("Param " + name + " must be in [" + low +
>> "-" + high + "]");
>> 
>> This is obviously ugly.  Other options would be to use
>> 
>>    String msg = String.format("Param %s must be in [%s-%s]", name, low,
>> high);
>>    logger.error(msg);
>>    throw new ValidationException(msg);
>> 
>> or
>> 
>>    String msg = MessageFormatter.format("Param {} must be in [{}-{}]", new
>> Object[] {name, low, high}).getMessage();
>>    logger.error(msg);
>>    throw new ValidationException(msg);
>> 
>> 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
>> 
>>    FormattingTuple entry = logger.format("Param {} must be in [{}-{}]",
>> name, low, high);
>>    logger.error(entry);
>>    throw new ValidationException(entry.getMessage());
>> 
>> 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).
>> 
>> </nk>
>> 
>> ---
>> 
>> 
>> Norbert Kiesel
>> Systems Architect, Engineering
>> E: nkie...@metricstream.com <sonia.sha...@metricstream.com>
>> W: www.metricstream.com
>> 
>> _______________________________________________
>> slf4j-user mailing list
>> slf4j-u...@qos.ch
>> http://mailman.qos.ch/mailman/listinfo/slf4j-user
>> 
>> 
>> --
>> Matt Sicker <boa...@gmail.com>
> 


Reply via email to