Хуже падающего приложения (Crash) может быть только приложение, которое «незаметно сломалось».
Пользователь жмет кнопку «Оплатить», а ничего не происходит. Лоадер покрутился и исчез. Приложение не упало, но функция не работает. Почему?
Потому что в коде написано это:
try {
api.buyPremium()
} catch (e: Exception) {
// TODO: обработать ошибку потом
print(e.message)
}
❌ Подход Джуна: Поймать ошибку, чтобы приложение не скрашилось, вывести её в консоль (
print или Log.e) и забыть. Но секрет в том, что консоль на телефоне реального пользователя никто не читает! Ошибка исчезает в пустоте.✅ Подход Мидла (Fail gracefully, log loudly):
Приложение должно мягко обработать ошибку для пользователя (показать красивый Снекбар «Упс, что-то пошло не так»), но при этом громко заорать об этом разработчикам.
🛠 Инструменты (Что должно быть в каждом проекте):
🔥 Firebase Crashlytics / Sentry:
Это не только для фатальных крашей! У них есть суперсила - Non-Fatal Exceptions (Нефатальные ошибки).
Вместо пустого
print, вы пишете:FirebaseCrashlytics.getInstance().recordException(e)Теперь каждое такое «тихое» падение сети или парсинга JSON прилетит вам на дашборд с аналитикой: у скольких пользователей это случилось, на каких моделях телефонов и версиях ОС.
🍞 Хлебные крошки (Breadcrumbs):
Представьте, что к вам прилетел краш:
NullPointerException на строке 42. Как его воспроизвести? Сеньоры добавляют логирование действий до ошибки:
Crashlytics.log("User opened Cart") -> Crashlytics.log("Clicked Checkout") -> Crash!Теперь вместе с краш-репортом вы получаете историю шагов пользователя. Баг фиксится за 5 минут вместо 5 часов гадания на кофейной гуще.
💡 Правило хорошего тона:
В Debug-сборке приложение должно падать с треском при любой неконсистентности данных (чтобы тестировщик или вы сразу это заметили). А в Release-сборке - пытаться выжить, но молча отправлять отчет вам на сервер.
Признавайтесь, много у вас в проекте забытых
TODO внутри catch? 👇#crashlytics #firebase #sentry #debugging #errors #android #ios #middle
👉 @developer_mobila