What is the industrial standard in identifying err...
# android
What is the industrial standard in identifying errors in production, without letting the user's app crash?
Crash is much better than hidden failure.
☝️ 4
💯 2
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"
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
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.
How do you push non-fatals to Firebase?
Thanks guys, I found
, looks like this is what I've been looking for
Copy code
throwableLogger = if (BuildConfig.DEBUG) Throwable::printStackTrace else Crashlytics::logException

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

try {
  // ...
} catch (e: LogicException) {
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.