#java #validation #exception #input
#java #проверка #исключение #ввод
Вопрос:
Мне было интересно, если, например, я считываю параметры для объектов из файла, учитывая этот метод, каков наилучший способ обработки этих исключений? Мой класс Auto имеет 4 параметра model, year, km, price :
public static Auto read(BufferedReader br) {
String model = br.readLine();
int year = Integer.parseInt(br.readLine());
int km = Integer.parseInt(br.readLine());
double price = Double.parseDouble(br.readLine());
return new Auto(model, an, km, pret);
}
Из моих показаний и того, что я нашел в качестве наилучшей практики, учитывая вероятность того, что пользователь может записать недопустимый ввод в файл, например, null для year или что-то в этом роде, я думаю, что лучше всего было бы что-то вроде этого:
public static Auto read(BufferedReader br) throws IOException, NumberFormatException{
String model = br.readLine();
int year = Integer.parseInt(br.readLine());
int km = Integer.parseInt(br.readLine());
double price = Double.parseDouble(br.readLine());
return new Auto(model, an, km, pret);
}
... // in main
try {
...
} catch (IOException e) {
//something
} catch (NumberFormatException e) {
throw new RuntimeException("Parsing to int/double failed, invalid input. Try again.", e);
}
Достаточно ли хорош мой подход?
Комментарии:
1. Вам нужно вручную считывать это из файла или вы можете использовать библиотеку для этой работы? Кроме того, можете ли вы применить определенный формат файла?
2. «каков наилучший способ обработки этих исключений» — это действительно зависит от контекста. Если это рукописный или отредактированный вручную файл, то, возможно , вам следует проявить снисходительность и перечислить все прерывистые строки как предупреждения, а в противном случае продолжить. Если действительно ожидается , что оно будет действительным, то наилучшим вариантом действий вполне может быть жесткий сбой — часто продолжать работу только с частично достоверными данными намного хуже, чем полностью остановиться. Мы не можем посоветовать вам, что лучше, потому что это зависит от вашего приложения, о котором мы ничего не знаем.
3. @JonSkeet Это всего лишь сценарий, используемый для практики, учитывая файл со многими параметрами, заданными для объектов (я не знаю, сколько), я должен прочитать их и в случае некоторого недопустимого ввода (например, null для синтаксического анализа), должен ли я перейти к нему или завершить программу с помощьюисключение во время выполнения. Я пытаюсь понять, какие стандарты следует использовать для производственного кода.
4. Я хочу сказать, что решение «должен ли я перейти к нему или завершить работу программы» — это выбор, который зависит от приложения. Это все равно, что спросить: «Должен ли я использовать строку или целое число?» без какого-либо контекста данных, которые вы пытаетесь представить. Производственный код должен делать правильные вещи для приложения, которое иногда будет быстро и сильно зависать, а иногда будет пропускать (но выделять) поврежденные данные. Не существует универсального правила.
5. Как насчет этих практических правил: 1) никогда не аварийно завершайте работу намеренно, если на самом деле нет способа продолжать; 2) если сначала вы думаете, что продолжать невозможно, подумайте еще раз ; 3) неправильный ввод людьми никогда не является приемлемым оправданием для сбоя стандартного производственного кода.