Яке загальне емпіричне правило при вирішенні питання про додавання throwsречення до методу чи використання символу try-catch?
З того, що я сам прочитав, throwsслід використовувати, коли абонент порушив свій кінець договору (переданий об'єкт), а try-catchслід використовувати, коли відбувається виняток під час операції, що виконується всередині методу. Це правильно? Якщо так, що робити з боку, хто телефонує?
PS: Шукали через Google та SO, але хотіли б отримати чітку відповідь на це.
Відповіді:
Загалом, метод повинен викликати виняток для свого абонента, коли він не може обробляти пов'язану проблему локально. Наприклад, якщо метод повинен читати з файлу із заданим шляхом, IOExceptionsне можна обробляти його локально розумним способом. Те саме стосується недійсного введення, додаючи, що моїм особистим вибором було б створити неперевірений виняток, як IllegalArgumentExceptionу цьому випадку.
І він повинен вловити виняток із викликаного методу, якщо:
DAOвикористання Hibernateдля збереження моїх сутностей, тому Я ловлю все HibernateExceptionsлокально і перетворюю їх у власні типи винятків).Ось спосіб використання:
Кидки:
Try-Catch:
Я знаю багатьох людей, які завжди використовують Throwс, тому що він чистіший, але просто не так багато контролю.
Моє персональне емпіричне правило для цього просте:
try/catch. Обробляючи це, я маю на увазі можливість повідомити користувача / відновитись після помилки або, в ширшому розумінні, мати можливість зрозуміти, як цей виняток впливає на виконання мого коду.Примітка: ці відповіді тепер є вікі спільноти. Не соромтеся додавати більше інформації в.
Рішення про додавання пропозиції try-catch або throws до ваших методів залежить від того, "як ви хочете (або повинні) обробляти ваші винятки".
Як вирішити виняток - це широке і далеко не тривіальне питання, на яке можна відповісти. Він спеціально передбачає рішення, де обробляти виняток і які дії реалізовувати в блоці catch. Насправді, як поводитися з винятком, має бути глобальним дизайнерським рішенням.
Тож відповідаючи на ваші запитання, не існує принципового правила.
Ви повинні вирішити, де ви хочете обробляти виняток, і це рішення, як правило, дуже специфічне для вашого домену та вимог програми.
Якщо метод, у якому було застосовано виняток, має достатню кількість інформації для боротьби з ним, тоді він повинен вловлювати, генерувати корисну інформацію про те, що сталося і які дані оброблялись.
Метод повинен бути лише throwsвинятком, якщо він може надати обґрунтовані гарантії стану об'єкта, будь-яких параметрів, переданих методу, та будь-яких інших об'єктів, на які діє метод. Наприклад, метод, який повинен отримати з колекції елемент, який абонент очікує міститися в ньому, може throwsмати перевірене виняток, якщо елемент, який, як очікувалося, існує в колекції, цього не робить. Абонент, який виявив цей виняток, повинен очікувати, що колекція не містить відповідного елемента.
Зауважте, що хоча Java дозволить перевіреним виняткам виділятися через метод, який оголошено як викид відповідних типів, таке використання, як правило, слід розглядати як анти-шаблон. Уявіть, наприклад, що якийсь метод LookAtSky()оголошений як виклик FullMoonException, і очікується, що він викине його, коли Місяць заповниться; уявіть далі, що LookAtSky()дзвінки ExamineJupiter(), які також оголошено як throws FullMoonException. Якщо a FullMoonExceptionбув кинутий ExamineJupiter(), і якщо LookAtSky()не впіймав його, або обробив його, або загорнув у якийсь інший тип винятку, код, який викликав LookAtSky, припускав би, що виняток був результатом заповнення місяця Землі; він не мав би поняття, що винуватцем може бути один із супутників Юпітера.
Винятки, які може очікувати обробник абонента (включаючи, по суті, всі перевірені винятки), повинні мати змогу просочуватися через метод, лише якщо виняток означатиме те саме, що викликає метод, як це означало для викликаного методу. Якщо код викликає метод, який оголошено як викидання якогось перевіреного винятку, але той, хто викликає, не очікує, що він коли-небудь викине цей виняток на практиці (наприклад, тому що вважає, що це попередньо перевірені аргументи методу), перевірений виняток слід перехопити та обернути у якомусь неперевіреному типі винятків. Якщо абонент не очікує, що буде виключено виняток, той, хто телефонує, не може очікувати, що це матиме якесь особливе значення.
Коли використовувати що. Я багато шукав про це. Жорсткого правила немає.
"Але як розробник, перевірені винятки повинні бути включені в пропозицію методу throws. Це необхідно для того, щоб компілятор знав, які виключення перевірити. За домовленістю, неперевірені винятки не повинні бути включені в пункт" броски ".
Включення їх розглядається як погана практика програмування. Компілятор розглядає їх як коментарі і не перевіряє їх ".
Джерело: книга SCJP 6 Кеті Сьєрри
пара try-catch використовується, коли ви хочете надати налаштування поведінки, у випадку, якщо виникає виняток ..... іншими словами ... у вас є рішення вашої проблеми (виникнення винятків) відповідно до вимог вашої програми .... .
Але throws використовується, коли у вас немає якогось конкретного рішення щодо випадку виникнення винятків ... ви просто не хочете отримувати ненормальне припинення вашої програми ....
Сподіваюся, це правильно :-)