As you very well know, we do not live in such an idyllic scenario. Crashes do happen. Hopefully when you’re developing, so they’re addressed before they make their way to QA (because you do have QA, right?). Or worse, your users.

When you catch crashes (or other issues that print stack traces) while developing, you have really nice clickable links in the IDE logcat view that bring you right to the problematic line of code.

Unfortunately, this world is far removed from that ideal of perfection. In real life, bugs make their way to QA, and even to end users. Now, when it happens, you’re likely receiving a stack trace copy-pasted into an email, a chat message, or an issue tracker ticket. There’s no nice clickable link.

java.lang.NullPointerException

at android.databinding.PropertyChangeRegistry$1.onNotifyCallback(PropertyChangeRegistry.java:28)

at android.databinding.PropertyChangeRegistry$1.onNotifyCallback(PropertyChangeRegistry.java:24)

at android.databinding.CallbackRegistry.notifyCallbacks(CallbackRegistry.java:201)

at android.databinding.CallbackRegistry.notifyFirst64(CallbackRegistry.java:122)

at android.databinding.CallbackRegistry.notifyRemainder(CallbackRegistry.java:169)

at android.databinding.CallbackRegistry.notifyRecurse(CallbackRegistry.java:145)

at android.databinding.CallbackRegistry.notifyCallbacks(CallbackRegistry.java:91)

at android.databinding.BaseObservable.notifyPropertyChanged(BaseObservable.java:62)

...

What most people do in this case is read the name of the class that is most likely to be the cause of the issue, switch to the project pane, look up the file, open it, and scroll to the line.