Разница между if else и try catch?

Question

[OldJohn]

Здравствуйте.
Допустим ситуацию в которой пользователь вводит число-делитель.
Как правильно проверить его корректность, через if, или выбросить соответствующее исключение?
Вообще интересует более абстрактный ответ. Когда использовать одно, а когда другое?

Answer 1

[Михаил]

Есть такой принцип: "если убрать все обработчики исключений, программа должна нормально функционировать при условии ввода корректных данных" (Д.Томас, Э.Хант "Программист-прагматик"). Поэтому вопрос - является ли введенный пользователем нуль корректными данными? Если да - то его надо оборачивать в if. Если же это некорректные с точки зрения программы данные - то можно кидать исключение.

То есть исключение должно выбрасываться при поступлении на вход программы некорректных данных. А какие именно данные считать некорректными - это определяет разработчик (или заказчик) программы.

Comments

[Фёдор]

Это применимо ко всем языкам программирования?

[Михаил]

Фёдор, я думаю да. По крайней мере к основным - Java, C++, C#, Python, Javascript и т.д.

[Василий Банников]

Фёдор, ну если исходить из того, что в хорошем коде исключения должны кидаться только в исключительных ситуациях, то да.

По крайней мере я не знаю ни одного языка, у которого в стандартной библиотеке были функции, которые кидают исключения/паникуют без исключительного повода.

[Inviz Custos]

По крайней мере я не знаю ни одного языка, у которого в стандартной библиотеке были функции, которые кидают исключения/паникуют без исключительного повода.

Василий Банников, зато сишный API винды при определенных условиях еще как может кидать исключения вместо того, чтобы просто вернуть FALSE :D

[Василий Банников]

Inviz Custos, при определенных условиях
Не кидают же они ОШИБКА {УСПЕХ}

Answer 2

[Max]

Имхо: Если есть возможность сделать без try catch, то лучше делать без try catch. Во всяком случае так работает с null pointer exception:

// Good
if (x != null) {
    
} else {

}

// Bad
try {
     // action with x
} catch(NullPointerEcxeption e) {

}

Answer 3

[nApoBo3]

Это древний холивар.

Личное мое имхо, исключение, это авариное завершение приложения, во всех не аварийных случаях их использовать не следуют, хотя бы из соображений производительности.

Comments

[Василий Банников]

Личное мое имхо

Не сказал бы. Так считают и разработчики языков:
C#:

The C# language's exception handling features help you deal with any unexpected or exceptional situations that occur when a program is running.

Java:

The term exception is shorthand for the phrase "exceptional event."
...
Definition: An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions.

C++:

Use exceptions for exceptional code.

Везде речь только об исключительных ситуациях.

Answer 4

[UniverseElement]

Если вы можете выполнить проверку условия в блоке if else, то используйте его + оберните его в try catch, чтобы перехватить непредвиденное исключение, если оно возникнет.

Answer 5

[Орхан Гасанлы]

Стоит также обратить внимание на то, что есть try with resources, что позволяет после работы автоматически закрывать соединение и т.д. Т.е. все, что имплементирует интерфейс AutoClosable. Например, подключиться к БД, что-то сделать, а затем закрыть соединение. Как мимнимум в if else этого нет.
С другой стороны try catch более тяжелый с точки зрения производительности.

Answer 6

[Николай Савельев]

Всегда надо помнить, что Исключение - это довольно дорогая операция и без необходимости лучше её не использовать

Answer 7

[mayton2019]

try-catch - это эволюционно развитый if-else. Вот те кто кодили на "C" знают как тяжело работать с файловыми операциями. Любой fopen,fread e.t.c. надо проверять на код возврата и обеспечивать аварийный выход с очисткой (!) всех ресурсов. И вот отслеживание всех ресурсов и их состояний это нетривиальная задача. Для этого создали try-with-resources. И вообще возврат в это тяжелое мракобесное время проверок errorcode - никому не советую.

В случае с делением на 0 (ArithmeticException). Если вы рисуете на экране график функции - то возможна ситуация
где будет много делений на нуль. Тогда обработка исключений может стать performance issue. Это правда.

Может помочь декомпозиция формулы с делением на результат с Option[Int] (в Scala и Java это уже рабоатет) и возвращать неопределенное значение None в случае когда в знаменателе стоит ноль. Вообще в языках ФП данный подход очень рекомендуется т.к. в этих языках есть синтаксический сахар для быстрого сворачивания (flatMap) списков таких опциональных значений.

Тоесть если вы из функции хотите вернуть пустоту - то возвращаете None вместо бросания прикладных исключений.

Comments

[Max]

None это в питоне, а в джаве null

[mayton2019]

scala> def divisionBy(a : Double, b : Double) : Option[Double] = if (b == 0.0) None else Some(a/b)

[Max]

mayton2019, это Scala?

[mayton2019]

Да

[Max]

mayton2019, я сказал что в java нет None, код на scala вообще никогда не видел до этого момента )

[mayton2019]

В Java все намного хуже. Мы либо можем возвращать из функции новый объект что само по себе тоже Performance Issue. Либо можно вернуть Double.NaN как признак того что вещественное число вышло кривое. Это технический долг который потянет за собой очень сложные и трудноуловимые эффекты в зависимом коде по стеку. И все кто юзают такую волшебную функцию в Java будут обязаны проверить на NaN (Not a Number) и принять решение.

Согласитесь в Scala все выглядит красиво и элегантно и главное типобезопасно.

[Василий Банников]

mayton2019, ну вообще Option и в жаве есть

[mayton2019]

Да. Я-же пишу про это. Возвращайте объект Optional. И сравнительный анализ перформанса должен быть следующим вопросом в qna. Примитивы против опциональных объектов. Или бросание исключений против возврата объектов из функций.