[ 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