Выкидываете исключения для контроля потока - запаха кода?

Question

Рассмотрим этот код (в частности, Java):

public int doSomething()
{
    doA();

    try {
        doB();
    } catch (MyException e) {
        return ERROR;
    }

    doC();
    return SUCCESS;
}

Где doB() определяется как:

private void doB() throws MyException

По существу, MyException существует только в том случае, если doB() удовлетворяет некоторому условию (которое не является катастрофическим, но должно каким-то образом повышать это условие), так что doSomething() будет знать, что выйти с ошибкой.

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

Answer 1

Смотрите топ ответ на этот вопрос:

Насколько медленны исключения Java?

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

Answer 2

Вы, ребята, убиваете меня здесь. Вы НИКОГДА не хотите использовать исключения для управления потоком. Это не сильно отличалось бы от повсеместного использования статистики goto!

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

Использование исключений в качестве управления потоком делает обслуживание и разработку новых функций настоящим кошмаром!

Answer 3

В C # создание исключений относительно дорого с точки зрения производительности & ndash; таким образом, еще одна причина, чтобы избежать их использования для управления потоком. Так ли это в Java? Да, есть аргумент, чтобы не переоценивать производительность заранее. Но если вы знаете, что что-то займет дополнительное время, и его легко избежать, разве вы не должны это делать? Если вам по-настоящему все равно!

Answer 4

Вот как бы я справился:

public void doSomething() 
        throws MyException{
    doA();

    try { 
        doB();
    } finally {
        doC();
    }
}

Если в doB () возникает ошибка, исключение будет распространяться вверх по стеку.

Answer 5

Как указали другие, это действительно зависит от предполагаемой функциональности методов, задействованных здесь. Если роль doSomething() состоит в том, чтобы что-то проверять, возвращая код, который позволяет продолжить нормальное выполнение его вызывающих методов (хотя и по разным путям в зависимости от возвращаемого кода), то возвращение этого значения int может быть нормальным. В этом случае, однако, doB(), вероятно, должен быть непротиворечивым и возвращать логическое значение или что-то, что doSomething() может проверить вместо выдачи исключения, которое на самом деле больше ничего не сделает.

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

Тот факт, что код, который вы возвращаете, когда doB() генерирует исключение, называется ERROR, однако, указывает на то, что это, вероятно, ошибка, которая помешает выполнению любой операции, частью которой является doSomething(). В этом случае вам, вероятно, не следует перехватывать исключение, генерируемое doB(), и просто разрешать его выбрасыванию в стек до тех пор, пока оно не достигнет точки, где оно может быть обработано, или пока оно не достигнет вашего общего обработчика ошибок, который может сообщить / зарегистрировать его или что угодно.

Answer 6

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