Пустые catch блоки это плохо?

Question

[BRONNER]

Вот упрощенный вариант того, как я использую Try-Catch

class Database {
    public void addRow() throws SQLException {
        try { /* Add row */ }
        catch(SQLException e) {
            log.error(e);
            throw e;
        }
    }
}

class Context1 {
    public void doSomething(Database db) throws SQLException {
        db.addRow(); //If throws exception then main exception handler executes sendMessage("failed");
        sendMessage("success");
    }
}

class Context2 {
    public void doSomething(Database db) {
        try { db.addRow(); }
        catch (SQLException ignored) {}
    }
}

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

Как быть в такой ситуации?

Answer 1

[Алексей Черемисин]

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

Comments

[BRONNER]

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

[Алексей Черемисин]

В этом случае (и остальных!!!) выкидывать его на самый верх в бизнеслогику. Я так и предпочитаю, все исключения как раз и должны быть на уровне бизнеслогики., остальное проверяется без исключений. Соответственно, все что можно выкидываем на верх, остальное проверяем.
Пример, открыть файл и если его нет, создать новый. Кажется, вот оно хорошее место для исключений - не ведитесь на это, просто проверьте перед открытием, что файло существует, и если нет, создайте его без исключений.
Тогда и ваш код будет совсем без try/catch, который будут только в самых существенных местах. Иногда, конечно, раздражает кортеж исключений в определении метода, ну так перейдите в этом случае на родителя (на класс выше) и будет щазтие. Ну и это как минимум повод задуматься, почему у меня тут и исключения от базы и от файлов и еще куча всякого... что-то явно не так тут...

[Алексей Черемисин]

И да, когда-то сам делал инициализацию через NullPointerException :-) , так что понимаю о чем пишу, да удобно, но как-то тормозливо, и как-то не там...

[BRONNER]

@leahch: У меня в первом контексте обработка исключений именно в одном месте и происходит, меня больше интересует второй, он выполняется в фоне по событию и никаких обработчиков нет. Я правильно понимаю, нужно убрать catch блок из метода addRow() и передать исключение дальше. В первом контексте передать исключение дальше главному обработчику, а во втором контексте ловить исключение и сообщить в консоль об ошибке и при необходимости прервать дальнейшее выполнение метода. Меня в принципе такое поведение устраивает

[Алексей Черемисин]

Если первый контекст не является финальным, то да, убираем тру/катч и передаем исключение дальше.
И если второй контекст является "финальным", то обрабатываем исключение и/или прерываемся, например этот контекст используется для логирования, то такое поведение нормально. Тем более, если нам захочется его как-то расширить, например передавать код ошибки через вебсервис, то мы легко это сделаем всего лишь в одном месте.

[BRONNER]

@leahch: Вот, это я и хотел уточнить, спасибо