Обработка исключений на протяжении всего жизненного цикла деятельности/фрагмента

Question

Итак, я пытаюсь понять, как лучше всего использовать исключения на Android.

Мой текущий подход:

• Бизнес логика/библиотеки обычно генерируют исключения из стека вызовов, так что может быть обработан, если исключение частично не ожидается, и могут быть обработаны локально.
• Все функции жизненного цикла деятельности, такие как onPause, onResume и т. Д., Имеют попытку catch. Они улавливают как исключение, так и мой собственный класс BusinessException. Для бизнес-исключений я показываю конкретную ошибку, а Exceptions показывает общую ошибку Oops, регистрируя фактическую ошибку в фоновом режиме.
• Обратные вызовы/прослушиватели и т. Д. Также имеют функцию try/catch и после исключения вызывают обратный вызов onFail/error.

Моя проблема заключается в том, что я получаю много попыток блокировки. Хотя это само по себе не так уж плохо, в каждом блоке catch у меня есть шаблонный код для регистрации ошибки. i.e prepping пары ключевых значений и т. д. Это просто кажется очень повторяющимся.

Что делают другие или какие-либо проекты с открытым исходным кодом, о которых вы знаете, на что я должен смотреть?

Thanks

Answer 1

Следующее в значительной степени мое мнение.

Бизнес-логика/библиотеки обычно генерируют исключения из стека вызовов, так что их можно обрабатывать, если исключение не ожидается и может быть обработано локально.

Местная обработка в порядке. Прекратить исключение, чтобы принудительная локальная обработка выше в стеке вызовов. В противном случае я бы использовал шину событий, чтобы рассказать о моем слое пользовательского интерфейса (если он существует), что проблема возникла, возможно, с помощью резервного механизма для подъема Notification, если пользователь должен знать о проблеме, и мы не находимся на переднем плане с точки зрения пользовательского интерфейса.

Все функции жизненного цикла деятельности, такие как onPause, onResume и т. Д., Имеют попытку захвата. Они улавливают как исключение, так и мой собственный класс BusinessException. Для бизнес-исключений я показываю конкретную ошибку, а Exceptions показывает общую ошибку Oops, регистрируя фактическую ошибку в фоновом режиме.

Обратные вызовы/прослушиватели и т. Д. Также имеют попытку/уловку, а после исключения вызывают обратный вызов onFail/error.

Я бы беспокоиться только о проверяемых исключениях и ожидаемых непроверенных исключениях (например, ActivityNotFoundException при вызове третьей стороны деятельности), следуя такой же подход, как я описал выше.

Для всего остального я бы разрешил мне по умолчанию неперехваченный обработчик исключений с ним, что в моем случае обычно ACRA.