Throwable или Exception?

Question

[Василий Жуков]

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

public void doAndForget() {
    try {
        service.doFirstPart();
        try {
            service.doSecondPart();
        } catch (Throwable t) {
            Log.warn(t);
            try {
                service.doRollbackSecondPart();
                try {
                    service.doRollbackFirstPart();
                } catch(Throwable t1) {
                    Log.error(t1);
                }
            } catch (Throwable t1) {
                Log.error(t1);
            }
        }
    } catch (Throwable t) {
        Log.warn(t);
        try {
            service.doRollbackFirstPart();
        } catch (Throwable t1) {
            Log.error(t1);
        }
    }
}

Почему Throwable, а не Exception? Боюсь. Вдруг какая-нибудь либа внутри кинет NoClassDefFoundError или AssertionError, тогда мы не откатимся. Да, вроде как, Error — это ошибки, которые даже не надо пытаться исправить, но я хочу исправить не ошибку, а то, что сделал мой код до нее. Да, вроде как, если упадет OutOfMemoryError, то текущий Thread должен просто умереть, но я хочу хотя бы попытаться восстановить состояние приложения.


Что скажут противники catchThrowable? Везде расставить catchException?

Answer 1

[Олег Яковенко]

А почему не упростить и не убрать кучу ненужных try?

public void doAndForget() {
     boolean firstOk = false;
     boolean secondOk = false;
     try{
          firstOk = service.doFirst();
          if (firstOk){ //Если есть какая то жесткая зависимость исхода выполнения
               secondOk = service.doSecond();
          }
     } catch(Чего угодно){
          Log.warn("Status 1 task: "+ firstOk+"; 2nd task "+secondOk;
     } finally {
          //Проверить флаги и вызвать откаты в нужной последовательности
     }

}

И всё же лучше не пытаться поймать какие то NoClassDefFound или там java.lang.OutOfMemoryError: PermGen space, в последнем случае там уже в памяти может быть всякая срань, не доработавший gc или что то. Данные могут быть уже не валидны или неверны.

Comments

[Олег Яковенко]

Да и вообще, ну хоть роллбеки то не должны с эксепшнами дико валиться. Или это просто попытка сделать приложение с гигантским запасом прочности?

Answer 2

[pletinsky]

Я не разработчик java — поэтому прошу прощения заранее, но в данном языке вроде есть finally блок, который придумали в том числе для организации роллбеков. Зачем Вам перехватывать ошибки мне вообще не понятно.

И судя по формулировки задачи try/finally блоков должно быть 2, а не 5 как у вас.

А по поводу собственно вопросов — не забывайте, что бывают ситуации, в которых вы все равно теряете уверенность в том, что вам удасться сделать rollback — как раз например OutOfMemoryError — и ваши действия могут привести к неожиданному результату. Приложение должно быть контролируемым.

Comments

[pletinsky]

Сорри — не try/finally блоки нужны — а try/catch блоки с дальнейшим пробросом эксепшена после выполнения роллбека.
Тоже 2 штуки конечно.

[pletinsky]

По поводу противников или сторонников перехвата Throwable — по моему тут не уместны холивары.
В официальной документации ясно сказано:

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a «normal» condition, is also a subclass of Error because most applications should not try to catch it.
A method is not required to declare in its throws clause any subclasses of Error that might be thrown during the execution of the method but not caught, since these errors are abnormal conditions that should never occur.

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

Answer 3

[relgames]

Можно применить немного функционального подхода и сделать, например, так

    public interface Transaction {
        void commit();
        void rollback();
    }

    public static void tryTransaction(Transaction tr) {
        try {
            tr.commit();
        } catch (Exception e) {
            //log.error....
            tr.rollback();
            throw new CommitException(...);
        }
    }

И вот как это использовать:

        tryTransaction(new Transaction() {
            @Override
            public void commit() {
                //step1
                //...

                //step2
                tryTransaction(new Transaction() {
                    ...
                });
            }

            @Override
            public void rollback() {
            }
        });

Тогда цепочка откатов выстроиться сама. Если ошибка случится на этапе rollback, то Exception просто передастся выше.

Answer 4

[Beholder]

В руководствах по Java обычно пишется, что перехватывать Error и его субклассы не стоит, так как если их кто-то выкинул, то это означает, что система (JVM или программа) уже на этот момент сломана настолько, что восстанавливаться бесполезно.