Комментарии 9
Какой смысл логировать HTTP ошибки на клиенте? Их же отдал сервер, пусть он и логирует.
Уже больше месяца авитовцы не могут мне исправить ошибку - в архиве "зависло" одно объявление, и не удаляется и зайти в него нельзя, потому что его нет. ТП сначала нафиг посылала, теперь завтраками кормит. Может через хабру можно достучаться до того программиста, который может это объявление удалить?
Разве не получается так, что большинство ошибок всё же вызваны или отсутствием соединения, или его качеством? В итоге логируются (условно бесполезные) ошибки сети, которые и отправить-то можно только после появления этой сети. Но когда сеть появилась, то и всё остальное тоже заработает нормально.
Хоть IO и составляют основную массу ошибок, ошибки приложения, библиотек и разношёрстных девайсов никуда не деваются. Да и IO – факт плохого пользовательского опыта и повод не забывать, в какой среде используется приложение. К тому же, например, может оказаться что какой-нибудь из HTTP-запросов отдаёт верный ответ, но на прокси ломается или в таймаут не вписывается и его нужно исправлять. Пусть логгируется как можно больше, а что нужно, а что не нужно уже потом видно будет.
По опыту Android, хорошо себя показывает Sentry, не только для крешей, но и при обработке прочих ошибок, с логгированием контекста (логи приложения уровня info и выше дублируются как breadcrumb, профиль пользователя и extra – в Sentry Context). Особенно, при использовании Logback, раз настроил appender и забыл. В случае iOS, хорошим вариантом мне видится SwiftLog с соответственно настроенным бэкендом логгера.
Ошибка.log(): как логируются ошибки в мобильном приложении Авито