0

The reason i ask what StackTraceElements are returned by new Throwable().getStackTrace() returns is because Timber#getTag method assumes that the 6th StackTraceElement is source of the log... e.g: new Throwable().getStackTrace()[5] == MainFragment Class or new Throwable().getStackTrace()[5] == Logging Class

Note: new Throwable().getStackTrace() is called at Timber#getTag, not where we are logging. While logging, we sometimes doesn't even pass a Throwable ( Timber.d("Fetching restaurants.") )

McKabue
  • 2,076
  • 1
  • 19
  • 34
  • 1
    That’s something horribly unreliable. I’ve seen both, `Throwable()` constructor included and excluded, in the wild. Once, I saw even `Throwable.fillInStackTrace()`, called by the constructor, included in the stack trace. If you want to use this way to determine the caller, you should check the actual stack frames in the array, to identify yourself first, then assume the next entry to be the caller (though, there is no standard regarding how to handle reflective calls). – Holger Nov 05 '18 at 10:44
  • thanks @Holger . i haven't done Java for long to understand it's intricate inner details, but i have quite a massive knowledge of similar languages and i can tell when i see something is done backward... – McKabue Nov 05 '18 at 12:22
  • 1
    Unfortunately, the contents of the stack trace array was never precisely specified, even worse, the documentation explicitly mentions the possibility that a particular implementation may omit stack frames for whatever technical reasons. It took until Java 9, before a standard way for programmatically examining the stack, or just getting the immediate caller (the `StackWalker` API) was introduced. That API also allows to specify whether reflection frames, etc. should be skipped or not. But I suppose, this has not yet made it into the Android API. – Holger Nov 05 '18 at 13:02

0 Answers0