оборачиваешь, когда упасть — нормально для этого кода. В остальных случаях дешевле кинуть исключение. На практике, запросы по сети обычно обернуты, потому что иначе в UI будет слишком легко что-то пропустить и не обработать.
так нет, обернуть в другое, более понятное исключение)
да в том и дело, что интересует, когда лучше обернуть во что-то более бизнесовое, как ProfileNotLoaded и тд
Я бы посоветовал всегда оборачивать. Во первых себе понятно. Во вторых стэктрейс сохраняется. В третьих на разные свои эксепшены можно выдавать разные ошибки
Совершенно не то. Помню из статей на хабре про код NASA. Смысл в том, чтобы в дебаг режиме можно было заметить и отследить все внештатные ситуации, чтобы исключения выкидывались по максимуму. А в прод режиме, чтобы ни одно исключение не положило систему.
Совершенно не то. Помню из статей на хабре про код NASA. Смысл в том, чтобы в дебаг режиме можно было заметить и отследить все внештатные ситуации, чтобы исключения выкидывались по максимуму. А в прод режиме, чтобы ни одно исключение не положило систему.
господа, вопрос как вы считаете, имеет ли смысл хранить андроид проджи на ссд? и, соответственно, с него и писать? или ему, ссд, так кранты придут, и лучше перенести на хдд?
Совершенно не то. Помню из статей на хабре про код NASA. Смысл в том, чтобы в дебаг режиме можно было заметить и отследить все внештатные ситуации, чтобы исключения выкидывались по максимуму. А в прод режиме, чтобы ни одно исключение не положило систему.
Этот вариант применим только если у тебя стоимость релиза полчаса
давай дополню: «отлавливайте ошибки во время тестирования и не допускайте их в релиз. для уверенности можете отправлять неотловленные ошибки в продакшене в систему сбора аналитики»