What is the industrial standard in identifying errors in pro kotlinlang #android

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.

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

pawegio

05/26/2020, 10:08 AM

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

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

👍 1

sindrenm

05/26/2020, 10:16 AM

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

05/26/2020, 10:16 AM

How do you push non-fatals to Firebase?

Vadym Shavalda

05/26/2020, 10:18 AM

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

Orhan Tozan

05/26/2020, 10:22 AM

Thanks guys, I found

FirebaseCrashlytics.getInstance().recordException(e)

, looks like this is what I've been looking for

pawegio

05/26/2020, 10:22 AM

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]

05/26/2020, 6:07 PM

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.

#android Join Slack