Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Don't concatenate message and throwable
See original GitHub issueI see in Timber$Tree:376 and Timber$Tree:382 that the stack trace was being appended in message. I think this is strange because the function Timber$Tree.log() receives the throwable as parameter.
Could be possible (or there is any option) not to concat the throwable into message and keep them separated?
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:7 (3 by maintainers)
Top Results From Across the Web
Avoid String concatenating for large log messages
One of the advantages of using something like slf4j is that it avoids String concatenation by using parameterized logging. However how ...
Read more >Avoid Concatenation in Logging Statements
Concatenated arguments in a logging message lead to concatenation and therefore an evaluation, even if the logging level is too low to show...
Read more >Throwable (MID Profile)
Returns a short description of this Throwable object. If this Throwable object was created with an error message string, then the result is...
Read more >Avoid String Concatenation
String concatenation in Java is a bad practice; this article explains why and how to avoid it to create cleaner code.
Read more >Strings should not be concatenated using '+' in a loop
Strings are immutable objects, so concatenation doesn't simply add the new String to the end of the existing string. Instead, in each loop...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Making
getStackTraceString()protected and non-final would make this configureable without being a breaking change. It’s not the cleanest solution, but could be a good interim fix prior to reworking in 5.0.@JakeWharton Would you be willing to accept a PR for this?
What about making it configurable?