Как обрабатывать деление на 0

ProgramBox

Как обрабатывать деление на 0

Post author:admin
Запись опубликована:2 мая, 2023
Post category:Вопросы по программированию

#java #android #try-catch

#java #Android #попробуй-поймай

Вопрос:

 if (getOperator=="/"){
    try {
        sum = value1/value2;
    } catch (Exception e) {
        summaryTxt.setText("Invalid operation");
    }
}

Что здесь не так?

1. Это не имеет прямого отношения к вашему вопросу, но вы никогда не должны сравнивать строки с == . Вместо этого используйте Equals. == предназначен для сравнения ссылок на память. Также либо вы используете имя получателя getOperator, а ваше отсутствует (), либо вам следует использовать лучшее имя (например, operator).

Ответ №1:

Это неправильно, и это плохая практика.

Представьте, что значение1 может быть целым числом, и оно равно null. Затем вы поймаете исключение NullPointerException, но ваш код сообщит вам, что операция недопустима, но это не так.

Исключения не предназначены для проверки условий. Лучше проверять их явно:

      if (getOperator=="/"){
        if (value2 == 0) {
           summaryTxt.setText("Value2 can't be 0!");
        } else {
           sum = value1/value2;
        }
      }

1. 1: Исключения никогда не следует использовать для управления потоком, особенно когда достаточно простых if-else проверок. @user655443: Если это сообщение не отображается, то value2 не равно нулю. И, следовательно, ошибки деления на ноль не будет.

2. Я пытаюсь if (getOperator==»/»){ { if (value2 == 0) { Log.d(«test», «eeee»); summaryTxt.setText(«» «Value2 не может быть 0!»); } else { сумма = значение1 /значение2; } } }

3. и это показывает «eeee» в Logcat, когда value2 = 0, но это не показывает «Value2 не может быть 0!»

4. Тогда это не связанная проблема. Задайте другой вопрос и покажите больше кода: как вы определяете summaryTxt, где выполняется этот код и так далее.

5. Кстати, кэширование исключения должно быть быстрее, чем использование if каждый раз, когда вы хотите разделить. Но просто при чтении кода и контекста влияние было бы незначительным. Это просто для того, чтобы включить один смысл среди других, кто-то предпочел бы перехватить арифметическую ошибку.

Ответ №2:

Деление на ноль вызовет исключение ArithmeticException, если значения являются, например, целыми числами, так что это то, что вы должны уловить.

Выполнение деления на ноль с использованием doubles вместо этого даст результат Double.Бесконечность

Ответ №3:

Я использую следующее для обработки деления на ноль и NaN:

 public static double safeDivide(double dividend, double divisor) {
    if(Double.compare(divisor, Double.NaN) == 0) return Double.NaN;
    if(Double.compare(dividend, Double.NaN) == 0) return Double.NaN;
    if(Double.compare(divisor, 0.0) == 0) {
        if(Double.compare(dividend, 0.0) == -1) {
            return Double.NEGATIVE_INFINITY;
        }
        return Double.POSITIVE_INFINITY;
    }
    if(Double.compare(divisor, -0.0) == 0) {
        if(Double.compare(dividend, -0.0) == 1) {
            return Double.NEGATIVE_INFINITY;
        }
        return Double.POSITIVE_INFINITY;
    }
    return dividend / divisor;
}

Ссылка:

math.stackexchange >> Я узнал, что 1/0 — это бесконечность, почему это не минус бесконечность?

Ответ №4:

Если вы хотите сделать это путем перехвата исключения, то:

 if (getOperator == "/") {
    try {
        sum = value1 / value2;
    } catch (ArithmeticException e) {
        summaryTxt.setText("Invalid operation: "   e.getMessage());
    }
}

Перехват Exception определенно плохая идея в целом, если не в данном конкретном случае. Проблема в том, что есть большая вероятность, что вы поймаете исключения другого типа, которые вы (программист) не ожидали; например, исключение NullPointerException в этом случае, если тип value1 или value2 является примитивным классом-оболочкой, а значение null .

Также спорно, следует ли вам реализовать это с помощью исключений или путем явного тестирования на ноль. ИМО, здесь приемлемлюбой способ. Деление на ноль, скорее всего, будет редким явлением для этого кода, и правило таково, что вы должны использовать исключения только в исключительных ситуациях. (Вам не обязательно, но вы можете …)

Тем не менее, я думаю, что я бы использовал явный тест на том основании, что это облегчает чтение кода.

 if (getOperator == "/") {
    if (value2 != 0) {
        sum = value1 / value2;
    } else {
        summaryTxt.setText("Invalid operation: divide by zero");
    }
}

(В сторону: getOperator == "/" это сомнительно, если только ваш код не гарантирует, что getOperator всегда содержит встроенную строку …)

Ответ №5:

Вы могли бы просто проверить, равно ли Значение2.(0); И выдать свое собственное исключение, если это так

Ответ №6:

напишите функцию расширения, подобную этой

     Double.safeDiv(other:Number,fallback:Double):Double {
       if(other == 0)
          return fallback
       else 
          return this / other
   }

где запасной вариант — это значение, которое вы хотите вернуть, когда делитель равен 0

Ответ №7:

 if (getOperator=="/" amp;amp; value2 == 0){
    summaryTxt.setText("Value2 can't be 0!");
}else if(getOperator=="/" amp;amp; != 0){
    sum = value1/value2;
}

такой красивый код)