What is the industrial standard in identifying errors in production, without letting the user's app ...

# android

[Orhan Tozan]

What is the industrial standard in identifying errors in production, without letting the user's app crash?

[pawegio]

Crash is much better than hidden failure.

[Orhan Tozan]

It sure is for the developer, but how is it in practice? Do the big apps also let the app crash when something is going wrong, even if it is non-breaking? Because as an app user, I can't recall the last time an app I used that crashed.

[Orhan Tozan]

And I'm talking about errors like "This shouldn't happen, but the app can still continue to work"

[pawegio]

Ok, so what you mean is a non-fatal error. If such app state is expected, business logic should handle the unhappy path.

[pawegio]

my approach:
• unexpected error -> crash the app
• expected (non-fatal) error -> handle it in app business logic

[sindrenm]

Also, depending on your logging framework of choice (we use Timber), you might be able to pipe your logs to where you see your crashes. We push both crashes and non-fatals to Firebase to have them in the same place.

[Orhan Tozan]

How do you push non-fatals to Firebase?

[Vadym Shavalda]

https://medium.com/@sembozdemir/using-timber-with-crash-reporting-tools-931eafd1296c

[Orhan Tozan]

Thanks guys, I found FirebaseCrashlytics.getInstance().recordException(e), looks like this is what I've been looking for

[pawegio]

throwableLogger = if (BuildConfig.DEBUG) Throwable::printStackTrace else Crashlytics::logException

fun log(throwable: Throwable) = throwableLogger.invoke(throwable)

try {
  // ...
} catch (e: LogicException) {
    log(e)
}

[Zach Klippenstein (he/him) [MOD]]

Rolling out updates gradually is also a useful technique to use with fail-fast crashing. You watch for spikes of crashes at every point in the rollout, so if something is broken you can fix it before most of your users ever get a chance to see the crash.