DivideByZeroException(). Зачем нужен?

Question

[Aleksey FRZ]

В чем преимущество DivideByZeroException() перед простым IFом ? Я могу с помощью if на 0 проверить.

public double CalcFraction1 (double x, double y)  { 
        var numerator = Math.Abs(x) - Math.Abs(y);
        var denominator = (1 + Math.Abs(x) * Math.Abs(y));
        if (denominator == 0)   { 
            throw new DivideByZeroException();
        }
        return numerator / denominator;

Answer 1

[aynur_safin]

https://msdn.microsoft.com/ru-ru/library/system.di...
Деление значения с плавающей запятой на ноль не вызывает исключения;

В чем преимущество DivideByZeroException() перед простым IFом ? Я могу с помощью if на 0 проверить.

Ну проверите вы на ноль, и то что вернете из функции? Если ноль, то это будет неверный результат.
Поэтому проверяем на ноль вручную и кидаем исключение, это лучше чем получить неверное значение.
Если не кидать исключение, то вернется "Infinity", оно вам надо? )

Comments

[Aleksey FRZ]

Я проверю на ноль ifом, если ноль, то вывести сообщение на экран допустим, что в знаменателе ноль и требуются такие то действия. Получается программа прервана и пользователь в курсе, что к чему. А в случае с исключением эффект тот же самый, только еще и производительность теряется. В чем я не прав?

[aynur_safin]

Если бы это была конечная программа, то другое дело - выводите куда хотите, что хотите.
Но это функция, и она может использоваться в какой угодно программе, хоть с гуем, хоть с консолью или вообще сервис без взаимодействия с пользователем, т.е. мы не знаем заранее, куда выводить сообщение пользователю. Поэтому при работе с этой функцией, её нужно обернуть в try-catch и ловить исключение, и когда поймаем, уже решаем что делать - писать пользователю и еще что-то.

Кстати, я что-то не могу придумать аргументы, при которых "denominator" будет равен нулю. )

[Aleksey FRZ]

aynur_safin: Очень доходчиво, я вот тоже не могу придумать. Спасибо

Answer 2

[Anton]

Если кратко то стиль кода.
Вы должны придерживаться парадигме ООП и если вы проверяете IFом условие, что у вас при делении не ноль, то это очень плохой то программирования.
Тем более при использовании exception вы вставляете в логику try...catch и тем самым можете перехватывать исключения и при необходимости передавать их компоненту который ответственнен за это

Comments

[denismaster]

С другой стороны, выброс исключения куда более нежелателен с точки зрения производительности, чем проверка с помощью if.

[Aleksey FRZ]

denismaster: где то читал, что надо всеми правдами и неправдами избавляться от вложенности, но ущерб производительности.

[denismaster]

Aleksey Bu: да, есть тенденция ухода от вложенности, но ее можно добиться другим способом, используя граничные условия.

//// Пример метода
int? DivideOrReturnNull(int a, int b)
{
    if(b==0) return null; // <--- Граничное условие
    ///дальше пошел код, в котором мы точно уверены, что деления на 0 нет.
    return a/b;
}

Таким образом, мы избавляемся от перехвата данного исключения. Аналогичный способ часто применятся в методах или конструкторах для проверки параметров на null.
Встречаются как ситуации, где исключения заменяют граничными условиями, так и наоборот, где условия заменяют исключительными ситуациями. Оба метода рефакторинга имеют право на жизнь.

Answer 3

[Howard Roark]

Не вижу смысла проверять на ноль, если в теле условия только выбрасывается исключение.
CLR и без вас выбросит DivideByZeroException, если denominator будет равен нулю.

Comments

[aynur_safin]

CLR и без вас выбросит DivideByZeroException, если denominator будет равен нулю.

Не выбросит, т.к. в числителе число с плавающей точкой.

[Howard Roark]

aynur_safin: а может ли в данном случае denominator быть числом меньшим чем 1 ?
Если я правильно понимаю, var denominator = (1 + Math.Abs(x) * Math.Abs(y)), функции Abs всегда будут возвращать положительные числа, и к результату умножения этих чисел добавляется еще и 1.

[aynur_safin]

Howard Roark: По моему, не может, я уже писал об этом в комментариях:
DivideByZeroException(). Зачем нужен?
тут скорее нужна проверка, на переполнение Double

if (double.IsInfinity(denominator)) 
{
  //
}

[Howard Roark]

aynur_safin: да, Вы правы

Answer 4

[d-stream]

Два примера:
1. некий огромный набор данных, по которому нечто рассчитывается
в исходных данных ноль недопустим - exception подразумевающее "все пропало" и прекращение действий (выбран не тот файл и т.п.)

2. тот же набор данных
в процессе сложных вычислений за счет округления один из делителей может округлиться до нуля... если это предсказуемо и допустимо - можно ветвиться if-ом и присваивать результату такого деления "псевдобесконечность" - например максимальное значения int и т.п. и далее продолжать вычисления

Answer 5

[Максим]

Выбрасывайте ArgumentException, он понятнее для пользователя функции, т.к. потребитель не знает, что внутри функции, и это его запутает.