[
https://issues.apache.org/jira/browse/CASSANDRA-14528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16518925#comment-16518925
]
mck commented on CASSANDRA-14528:
---------------------------------
{quote}Do you really need the nested String.format() within the logger lines?
Why not just pass the exception as the final arg?{quote}
Yes. See CASSANDRA-13723
The {{logger}} parameters for methods {{error(…)|warn(…)|log(…)|debug(…)}} is
either {{(String, Throwable)}} or {{(String, Object…)}}.
So as soon as there's one format argument, then any tailing exception will also
be interrupted as a format argument, and we get {{exception.toString()}}.
CASSANDRA-13723 improved that situation, replacing {{exception.toString()}}
with {{exception.getMessage()}}. While this ticket re-introduces the stack
traces.
> Provide stacktraces for various error logs
> ------------------------------------------
>
> Key: CASSANDRA-14528
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14528
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Stefan Podkowinski
> Assignee: Stefan Podkowinski
> Priority: Major
> Fix For: 4.x
>
>
> We should reintroduce some stack traces that have gone missing since
> CASSANDRA-13723 (ba87ab4e954ad2). The cleanest way would probably to use
> {{String.format}} for any custom messages, e.g.
> {{logger.error(String.format("Error using param {}", param), e)}}, so we make
> this more implicit and robust for coming api changes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
