Справжнє рішення в Java: проаналізуйте 2 числа з 2 рядків, а потім поверніть їх суму

Досить дурне запитання. Даний код:

public static int sum(String a, String b) /* throws? WHAT? */ {
  int x = Integer.parseInt(a); // throws NumberFormatException
  int y = Integer.parseInt(b); // throws NumberFormatException
  return x + y;
}

Не могли б ви сказати, хороша це Java чи ні? Те, про що я кажу, NumberFormatException- це неперевірений виняток. Вам не потрібно вказувати це як частину sum()підпису. Більше того, наскільки я розумію, ідея неперевірених винятків полягає лише у сигналізації про те, що реалізація програми є неправильною, і навіть більше, ловити неперевірені винятки - погана ідея, оскільки це як виправлення поганої програми під час виконання .

Хтось, будь ласка, пояснить, чи:

1. Я повинен вказати NumberFormatExceptionяк частину підпису методу.
2. Мені слід визначити власний перевірений виняток ( BadDataException), обробити NumberFormatExceptionвсередині методу і перекинути його як BadDataException.
3. Я повинен визначити власний перевірений виняток ( BadDataException), перевірити обидва рядки якимось чином, як регулярні вирази, і викинути мій, BadDataExceptionякщо він не збігається.
4. Ваша ідея?

Оновлення :

Уявіть, це не фреймворк з відкритим кодом, який вам слід використовувати з якихось причин. Ви дивитесь на підпис методу і думаєте - "Добре, це ніколи не кидає". Потім, одного дня, ви отримали виняток. Це нормально?

Оновлення 2 :

Є деякі коментарі, які говорять, що мій sum(String, String)поганий дизайн. Я абсолютно згоден, але для тих, хто вважає, що оригінальна проблема просто не з’явилася б, якби ми мали гарний дизайн, ось додаткове запитання:

Визначення проблеми таке: у вас є джерело даних, де числа зберігаються як Strings. Це джерело може бути XML-файлом, веб-сторінкою, вікном робочого столу з 2 полями для редагування.

Ваша мета полягає в тому, щоб реалізувати логіку, яка приймає ці 2 Stringс, перетворює їх на ints і відображає вікно повідомлення "Сума xxx".

Незалежно від того, який підхід ви використовуєте для проектування / реалізації цього, ви будете мати ці 2 пункти внутрішньої функціональності :

1. Місце , де ви перетворити Stringвint
2. Місце, де ви додаєте 2 intс

Основне питання мого оригінального допису:

Integer.parseInt()очікує, що буде передано правильний рядок. Всякий раз, коли ви передаєте неправильний рядок , це означає, що ваша програма неправильна (а не " ваш користувач ідіот"). Вам потрібно реалізувати шматок коду там, де з одного боку ви маєте Integer.parseInt () із семантикою MUST, а з іншого боку, вам потрібно бути в порядку з випадками, коли введення неправильне - СЛІД семантики .

Отже, коротко: як мені реалізувати СЛІД семантику, якщо у мене є лише ОБОВ’ЯЗКОВІ бібліотеки .

Це гарне запитання. Я хотів би, щоб більше людей думало про такі речі.

ІМХО, кидання неперевірених винятків є прийнятним, якщо вам передали параметри сміття.

Взагалі кажучи, ви не повинні кидати, BadDataExceptionтому що ви не повинні використовувати винятки для управління потоком програм. Виняток становлять виключні. Викличники вашого методу можуть знати, перш ніж вони його викличуть, чи є їх рядки цифрами чи ні, тому передавання сміття можна уникнути, і тому його можна вважати помилкою програмування , а це означає, що викидати непровірені винятки можна.

Щодо декларування throws NumberFormatException- це не настільки корисно, тому що мало хто помітить через те, що NumberFormatException не позначено. Однак IDE можуть цим скористатися і запропонувати правильно обернутися try/catch. Хороший варіант - використовувати також javadoc, наприклад:

/**
 * Adds two string numbers
 * @param a
 * @param b
 * @return
 * @throws NumberFormatException if either of a or b is not an integer
 */
public static int sum(String a, String b) throws NumberFormatException {
    int x = Integer.parseInt(a); 
    int y = Integer.parseInt(b); 
    return x + y;
}

ВИДАВАНО : Коментатори
зробили дійсні бали. Вам потрібно врахувати, як це буде використано, та загальний дизайн вашого додатка.

Якщо метод буде використовуватися повсюдно, і важливо, щоб усі абоненти обробляли проблеми, оголосіть метод як викидання перевіреного винятку (змушуючи абонентів вирішувати проблеми), але захаращуючи код try/catchблоками.

Якщо, з іншого боку, ми використовуємо цей метод з даними, яким ми довіряємо, тоді оголосіть його, як зазначено вище, тому що він, як очікується, ніколи не вибухне, і ви уникаєте безладу коду по суті непотрібних try/catchблоків.

На мій погляд, було б бажано обробляти логіку винятків якомога вище. Тому я віддав би перевагу підпису

 public static int sum(int a, int b);

З вашим підписом методу я б нічого не міняв. Або ти

• Програмно використовуючи неправильні значення, де замість цього ви можете перевірити свій алгоритм виробника
• або надсилання значень з, наприклад, вводу користувача, і в цьому випадку модуль повинен виконувати перевірку

Отже, обробка винятків у цьому випадку стає проблемою документації .

Число 4. Як зазначено, цей метод не повинен приймати рядки як параметри, він повинен приймати цілі числа. У цьому випадку (оскільки Java обгортається, а не переповнюється), немає можливості виключення.

 x = sum(Integer.parseInt(a), Integer.parseInt(b))

набагато зрозуміліше, що мається на увазі, ніж x = sum(a, b)

Ви хочете, щоб виняток стався якомога ближче до джерела (введення).

Що стосується варіантів 1-3, ви не визначаєте виняток, оскільки ви очікуєте, що ваші абоненти вважатимуть, що в іншому випадку ваш код не може вийти з ладу, ви визначаєте виняток, щоб визначити, що відбувається за відомих умов відмови, ЯКІ УНІКАЛЬНІ ДЛЯ ВАШОГО МЕТОДУ. Тобто якщо у вас є метод, який є обгорткою навколо іншого об’єкта, і він видає виняток, потім передайте його. Тільки якщо виняток є унікальним для вашого методу, ви повинні кидати спеціальний виняток (frex, у вашому прикладі, якщо сума повинна була повертати лише позитивні результати, тоді перевірка на це та додавання винятку буде доречним, якщо з іншого боку java викинув виняток із переповнення замість обгортання, тоді ви передали б його, а не визначали у своєму підписі, перейменовували або з'їдали)

Оновлення у відповідь на оновлення питання:

Отже, коротко: як мені реалізувати СЛІД семантику, якщо у мене є лише ОБОВ’ЯЗКОВІ бібліотеки.

Рішенням цього є обгортання бібліотеки MUST та повернення значення SHOULD. У цьому випадку функція, яка повертає ціле число. Напишіть функцію, яка приймає рядок і повертає об’єкт Integer - або вона працює, або повертає null (як Ints.tryParse гуави). Якщо ваша перевірка відокремлена від вашої операції, ваша операція повинна приймати інт. Чи буде ваша операція викликатися зі значеннями за замовчуванням, якщо у вас невірний ввід, або ви робите щось інше, буде залежати від ваших специфікацій - найбільше, що я можу сказати про це, це те, що насправді малоймовірно, що місце для прийняття такого рішення є в операції метод.

1. Я повинен вказати NumberFormatException як частину підпису методу.

Я думаю так. Це гарна документація.

2. Мені слід визначити власний перевірений виняток (BadDataException), обробити NumberFormatException усередині методу і повернути його як BadDataException.

Іноді так. У деяких випадках перевірені винятки вважаються кращими, але робота з ними - це цілком ПІТА. Ось чому багато фреймворків (наприклад, Hibernate) використовують лише винятки під час виконання.

3. Я повинен визначити власний перевірений виняток (BadDataException), перевірити обидва рядки якимось чином, як регулярні вирази, і кинути мій BadDataException, якщо він не збігається.

Ніколи. Більше роботи, менша швидкість (за винятком випадків, коли викидання винятку буде правилом), і ніякого виграшу зовсім.

4. Ваша ідея?

Зовсім ні.

№ 4.

Думаю, я б зовсім не міняв метод. Я б поставив спробу ловити навколо методу виклику або вище в стеці-трасування, де я перебуваю в контексті, де я можу витончено відновити бізнес-логіку з винятку.

Я б не впевнено зробив No3, оскільки вважаю це надмірним.

Якщо припустити, що те, що ви пишете, буде спожито (наприклад, як API) кимось іншим, тоді вам слід вибрати 1, NumberFormatException призначений спеціально для передачі таких винятків і повинен використовуватися.

1. Спочатку потрібно запитати у себе, чи потрібно користувачеві мого методу турбуватися про введення неправильних даних, чи від нього очікується введення належних даних (у цьому випадку рядка). Це очікування також відоме як дизайн за контрактом .

2. та 3. Так, ви, мабуть, повинні визначити BadDataException або навіть краще використовувати деякі із вирізаних, таких як NumberFormatException, а залишити стандартне повідомлення для показу. Зловлюйте NumberFormatException у методі та повторно додайте його разом із вашим повідомленням, не забуваючи включити оригінальну трасування стека.

3. Це залежить від ситуації, але я б, мабуть, пішов із повторним викидом NumberFormatException із деякою додатковою інформацією. А також має бути роз'яснення javadoc щодо того, для чого очікуються значенняString a, String b

Багато залежить від сценарію, в якому ви знаходитесь.

Випадок 1. Завжди ви, хто налагоджує код, і ніхто інший, ані виняток, не спричинятимуть поганого користувацького досвіду

Киньте за замовчуванням NumberFormatException

Випадок 2: Кодекс повинен бути надзвичайно ремонтопридатним та зрозумілим

Визначте власний виняток і додайте набагато більше даних для налагодження під час його викидання.

Вам не потрібні перевірки регулярних виразів, оскільки вони все одно перейдуть на виняток із поганим введенням.

Якби це був код виробничого рівня, моя ідея полягала б у визначенні декількох спеціальних винятків, наприклад

1. Виняток формату чисел
2. Виняток із переповнення
3. Нульовий виняток тощо ...

і мати справу з усім цим окремо

1. Ви можете зробити це, щоб зрозуміти, що це може статися за неправильне введення. Хтось, хто використовує ваш код, може допомогти запам’ятати цю ситуацію. Більш конкретно, ви чітко даєте зрозуміти, що самі не обробляєте це в коді або замість цього повертаєте якесь конкретне значення. Звичайно, JavaDoc також повинен це чітко пояснити.
2. Тільки якщо ви хочете змусити абонента мати справу з перевіреним винятком.
3. Це здається надмірним. Покладайтеся на синтаксичний аналіз, щоб виявити неправильний вхід.

Взагалі, NumberFormaException не позначено, оскільки передбачається, що надано правильно розбірний вхід. Перевірка вводу - це те, з чим вам слід поводитися. Однак насправді розбір вхідних даних - це найпростіший спосіб зробити це. Ви можете просто залишити свій метод таким, як він є, і попередити в документації, що очікується правильне введення, і кожен, хто викликає вашу функцію, повинен перевірити обидва входи перед використанням.

Будь-яка виняткова поведінка повинна бути роз'яснена в документації. Або слід зазначити, що цей метод повертає спеціальне значення у випадку відмови (наприклад null, шляхом зміни типу повернення на Integer) або випадку 1. Визначення його в підписі методу дозволяє користувачеві ігнорувати його, якщо він забезпечує правильні рядки іншими засобами, але все одно очевидно, що метод не справляється з таким видом відмов сам по собі.

Відповідь на ваше оновлене запитання.

Так, цілком нормально отримувати "сюрпризні" винятки. Подумайте про всі помилки часу виконання, які виникають, коли з’являються нові програми.

e.g ArrayIndexOutofBound

Також поширений сюрприз виняток з для кожного циклу.

ConcurrentModificationException or something like that

Незважаючи на те, що я погоджуюсь з відповіддю на те, що виняток виконання має бути дозволено виконувати, з точки зору дизайну та зручності використання, було б непогано обернути його в IllegalArgumentException, а не кидати як NumberFormatException. Потім це робить контракт вашого методу більш чітким, де він оголошує, що йому передано незаконний аргумент, через який він створив виняток.

Щодо оновлення запитання "Уявіть, це не фреймворк з відкритим кодом, який вам слід використовувати з якихось причин. Ви дивитесь на підпис методу і думаєте -" Добре, це ніколи не кидає ". Потім, одного дня, ви отримали виняток Це нормально? " javadoc вашого методу завжди повинен розкривати поведінку вашого методу (обмеження до і після). Подумайте про рядки інтерфейсів збірки сказати, де, якщо нуль не дозволений, javadoc каже, що буде викинуто виняток нульового вказівника, хоча це ніколи не є частиною підпису методу.

Оскільки ви говорите про хорошу Java-практику, на мій погляд, це завжди краще

• Щоб обробити неперевірений виняток, проаналізуйте його та за допомогою спеціального неперевіреного винятку.

• Також під час викиду нестандартного виключення ви можете додати повідомлення про виняток, яке ваш клієнт міг зрозуміти, а також надрукувати трасування стека вихідного винятку

• Не потрібно оголошувати спеціальний виняток як "кидає", оскільки він не встановлений.

• Таким чином ви не порушуєте використання того, для чого створені неперевірені винятки, в той же час клієнт коду легко зрозуміє причину та рішення для винятку.

• Також належне документування у java-doc є гарною практикою і дуже допомагає.

Я думаю, це залежить від вашої мети, але я б задокументував це як мінімум:

/**
 * @return the sum (as an int) of the two strings
 * @throws NumberFormatException if either string can't be converted to an Integer
 */
public static int sum(String a, String b)
  int x = Integer.parseInt(a);
  int y = Integer.parseInt(b);
  return x + y;
}

Або візьміть сторінку з вихідного коду Java для класу java.lang.Integer:

public static int parseInt(java.lang.String string) throws java.lang.NumberFormatException;

Як щодо шаблону перевірки вводу, реалізованого бібліотекою Google „Guava“ або бібліотекою Apache „Validator“ ( порівняння )?

З мого досвіду вважається гарною практикою перевіряти параметри функції на початку функції та викидати винятки, де це доречно.

Крім того, я вважав би це питання в основному незалежним від мови. Тут “хороша практика” стосуватиметься всіх мов, які мають функції, які можуть приймати параметри, які можуть бути або не бути дійсними.

Я думаю, що ваше перше речення "Досить дурне питання" є дуже актуальним. Чому б вам коли-небудь писати метод із таким підписом? Чи є сенс взагалі підсумовувати два рядки? Якщо метод, що викликає, хоче підсумувати два рядки, відповідальність методу, що викликає, полягає в тому, щоб переконатися, що вони є дійсними ints, і перетворити їх перед викликом методу.

У цьому прикладі, якщо метод виклику не може перетворити два рядки в int, він може зробити кілька речей. Це насправді залежить, на якому шарі відбувається це підсумовування. Я припускаю, що перетворення рядка було б дуже близьким до інтерфейсного коду (якби це було зроблено належним чином), такий випадок 1. був би найімовірнішим:

1. Встановіть повідомлення про помилку та припиніть обробку або переспрямування на сторінку помилки
2. Повернути false (тобто, це містило б суму в якийсь інший об'єкт і не вимагало б її повернення)
3. Викиньте BadDataException, як ви пропонуєте, але якщо підсумовування цих двох чисел не є дуже важливим, це надмірне, і, як уже згадувалося вище, це, мабуть, поганий дизайн, оскільки це означає, що перетворення здійснюється не в тому місці

На це питання є багато цікавих відповідей. Але я все одно хочу додати це:

Для розбору рядків я завжди волію використовувати "регулярні вирази". Нам допоможе пакет java.util.regex. Тож я закінчу щось подібним, що ніколи не створює жодних винятків. Мені потрібно повернути спеціальне значення, якщо я хочу виявити якусь помилку:

import java.util.regex.Pattern;
import java.util.regex.Matcher;

public static int sum(String a, String b) {
  final String REGEX = "\\d"; // a single digit
  Pattern pattern = Pattern.compile(REGEX);
  Matcher matcher = pattern.matcher(a);
  if (matcher.find()) { x = Integer.matcher.group(); }
  Matcher matcher = pattern.matcher(b);
  if (matcher.find()) { y = Integer.matcher.group(); }
  return x + y;
}

Як бачимо, код трохи довший, але ми можемо обробляти те, що хочемо (і встановлювати значення за замовчуванням для x та y, контролювати те, що відбувається з реченнями else тощо). Ми могли б навіть написати більш загальне перетворення підпрограма, до якої ми можемо передавати рядки, стандартні значення повернення, код REGEX для компіляції, повідомлення про помилки для викидання, ...

Сподіваюся, це було корисно.

Попередження: Я не зміг протестувати цей код, тому, будь ласка, вибачте за можливі проблеми із синтаксисом.

Ви стикаєтеся з цією проблемою, оскільки дозволяєте помилкам користувача поширюватися занадто глибоко в ядро ​​програми, а частково також через зловживання типами даних Java.

Ви повинні чіткіше відокремити перевірку введення користувачем від бізнес-логіки, використовувати належний набір даних, і ця проблема зникне сама собою.

Справа в тому, що семантика Integer.parseInt()відома - це основна мета аналізу дійсних цілих чисел. Вам не вистачає явного кроку перевірки / аналізу вводу користувача.