Я працюю над додатком для Android, який try/catchчасто використовує для запобігання його збою навіть у місцях, де немає потреби. Наприклад,
Погляд у xml layoutз id = toolbarпосилається на:
// see new example below, this one is just confusing
// it seems like I am asking about empty try/catch
try {
View view = findViewById(R.id.toolbar);
}
catch(Exception e) {
}
Цей підхід використовується у всій програмі. Трасування стека не друкується, і насправді важко знайти, що пішло не так. Додаток раптово закривається, не надрукувавши жодного сліду стека.
Я попросив свого старшого пояснити мені це, і він сказав:
Це для запобігання збоїв у виробництві.
Я абсолютно з цим не згоден . Для мене це не спосіб запобігти збоям програм. Це показує, що розробник не знає, що він / вона робить, і сумнівається.
Чи такий підхід використовується у промисловості для запобігання збоїв корпоративних програм?
Якщо try/catchце насправді, насправді наша потреба, то чи можна приєднати обробник винятків за допомогою потоку інтерфейсу користувача або інших потоків і вловити все там? Це буде кращий підхід, якщо це можливо.
Так, порожньо try/catchпогано , і навіть якщо ми виводимо трасування стеки або виключення журналу на сервер, упаковка блоки коду в try/catchвипадковому порядку по всьому додатком не мають сенсу для мене , наприклад , коли кожна функція полягає в try/catch.
ОНОВЛЕННЯ
Оскільки це питання привернуло багато уваги, і деякі люди неправильно його інтерпретували (можливо, тому, що я його не сформулював чітко), я збираюся переформулювати його.
Ось що тут роблять розробники
Функція записується і тестується , це може бути невелика функція, яка просто ініціалізує подання, або складна, після тестування вона обертається навколо
try/catchблоку. Навіть для функції, яка ніколи не призведе до винятків.Ця практика використовується у всій програмі. Іноді трафік стека друкується, а інколи просто a
debug logіз деяким випадковим повідомленням про помилку. Це повідомлення про помилку відрізняється від розробника до розробника.При такому підході програма не виходить з ладу, але поведінка програми стає невизначеною. Навіть іноді важко простежити, що пішло не так.
Справжнім запитанням, яке я задавав, було; Чи дотримується у галузі практика запобігання збоїв корпоративних програм? і я не питаю про порожні спроби / лови . Це як, користувачі люблять програми, які не виходять з ладу, ніж програми, які ведуть себе несподівано? Тому що це справді зводиться або до його збою, або перед користувачем порожнім екраном, або поведінки, про яку користувач не знає.
Я публікую тут кілька фрагментів з реального коду
private void makeRequestForForgetPassword() { try { HashMap<String, Object> params = new HashMap<>(); String email= CurrentUserData.msisdn; params.put("email", "blabla"); params.put("new_password", password); NetworkProcess networkProcessForgetStep = new NetworkProcess( serviceCallListenerForgotPasswordStep, ForgotPassword.this); networkProcessForgetStep.serviceProcessing(params, Constants.API_FORGOT_PASSWORD); } catch (Exception e) { e.printStackTrace(); } } private void languagePopUpDialog(View view) { try { PopupWindow popupwindow_obj = popupDisplay(); popupwindow_obj.showAsDropDown(view, -50, 0); } catch (Exception e) { e.printStackTrace(); } } void reloadActivity() { try { onCreateProcess(); } catch (Exception e) { } }
Це не дублікат найкращих практик обробки винятків Android , тому OP намагається вловити виняток з іншою метою, ніж це питання.
catch(Exception e){}- цей коментар мав сенс до редагування питання