cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "mck (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-14528) Provide stacktraces for various error logs
Date Thu, 21 Jun 2018 05:30:00 GMT


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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message