I thought it’d be fun to take a poll: In productio...

# android

[spierce7]

I thought it’d be fun to take a poll:
In production one of my companies server team recently did a release where they broke the contract of an endpoint. One app immediately crashed after login with a JSON serialization exception, and another app caught the exception, ‘gracefully’ failing, showing a blank screen to the user after login. We found the issue and reverted the server changes quickly because we got alerts from crashlytics that we had a crash that an abnormal number of users experienced in a very small time frame.

Use the ‘YES’ emote on this post if you think the application should crash, and use the ‘NO’ emote if you think the app should gracefully fail, with a blank screen, or perhaps a dialog or something.

Feel free to explain why in the thread, or perhaps offer an alternative solution that you feel is better.

[yaaash]

If the app crashes it is immediately added as a top crash in your crashlytics which can be fixed asap. But if the app shows blank screen, it may take 10 - 12 hours or a day for one to realize if any issue is occurring.

[yaaash]

always best solution - Crash it!

[Pablichjenkov]

You can track caught exceptions and customer events too. Let it crash I don't think applies for mobile even from a Marketing perspective. You never hear, Facebook App crashed all this week but you might have seen a couple of dialogs saying, Network Error try later.
If you know a region of your code can be a source of exceptions, why not handling it properly. Some of them might be recoverable.
I grew up in a world where if the App crashes you are fired. Maybe I am still traumatized. ☹️

[yaaash]

😂 I think we all live in the same world. 😛

[yaaash]

One can always add checks but if it is at login page or splash - keep showing a dialog is same as crash

[Pablichjenkov]

That's right.
It's really a Marketing issue. Although in general handling errors help understand better the system.
The Dialog also save your moral as a mobile developer. Since you can blame the internet provider on your Null Pointer Exception 🙂

[Luca Nicoletti]

No crash with dialog and custom report to you in order to be able to spot the problem

[Jan Skrasek]

All my API calls are wrapped to catch networking issues and serialization issues. So the app gracefully flows into no internet usecase. But! The wrapper track the exceptions differently. E.g. 500 http error is not logged, some 4xx are and others are also sent to crashlytics. (They are the non fatal) so we can react quite quickly too.

[Jan Skrasek]

Crashing the app is always bad, users will report their frustration as app rating, Google play vitals will go down...

[ghedeon]

Depends... I've seen people blindly pushing this "never crash the app" policy too far. To the point of no recovery, when the app is stuck in a loop of "Something went wrong" dialogs and empty screens. If you add poor tracking to the mix and no QA, who knows how many days users will stare on your useless app until somebody reports the issue. There is nothing "graceful" here, plus the amount of effort to "handle" it no matter what... Sometimes, I'm thinking that small staged rollout + crash the fuckn' app is much better, you know, fail fast and stuff 🙂.

[spierce7]

@Jan Skrasek We saw no bad reviews from the incident with 250+ users encountering the crash I think. And even if we did,

The ideal situation would be to catch non-fatal issues in crashlytics, but does Crashlytics / Firebase handle non-fatal issues the same in terms of reporting etc?

[Xavier F. Gouchet]

Usually I have a mechanism to let the app crash on Dev environment/debug builds, and fail gracefully with an error message in release/prod. That way a user will never (or rarely) experience a crash, but you can detect things early during your QA / dev phase.

[Xavier F. Gouchet]

In addition, we also send "caught" exceptions to crashlytics anyway allowing us to see them early if they only happen in prod.

[Fatih Yalmanbas]

Yes and No, default should crash. But catch uncaught exceptions and track them so that backend / client can fix it.

[Matej Drobnič]

@Scott Both Fabric and Firebase (they have the same API anyway) support logging custom exceptions. Then you can filter them in the UI (crashes, non-crashes or all)

[Matej Drobnič]

but in all other aspects they are identical (you can still see stack trace and all associated information)

[Matej Drobnič]

As for the answer to original question, I'm also on the "display user-friendly error message and report the problem to whatever error reporting service you use" side

[Matej Drobnič]

It is much better experience for the user than app just suddenly closing on him (most phones do not display force close dialog anymore, so app just closes as if you pressed home button).