Лучшие практики обработки исключений Java и предотвращение ошибок

Java

предисловие

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

текст

Классификация аномалий

Прежде всего, здесь я нарисовал блок-схему классификации исключения.

В JDK Throwable является родительским классом всех исключений, которые делятся на «Ошибки» и «Исключения». Ошибка означает неконтролируемую серьезную ошибку, такую ​​как OutOfMemoryError. Исключения подразделяются на две категории: проверенное исключение (проверка) требует, чтобы мы вручную пробовали/отлавливали или выбрасывали определение метода, а компилятор проверит его правильность при компиляции. Непроверенные исключения (unchecks) не требуют от нас обработки их заранее. Эти простые понятия должны быть освоены разработчиками.Вот легенда без подробного описания.Наш "ужин" еще позади.

Откройте для себя заново попробовать/поймать/наконец-то

Когда дело доходит до обработки исключений, здесь нужно упомянуть try/catch/finally. try не может существовать сам по себе, ни с catch, ни с finally, ни со всеми тремя.
1. попробуйте блок кода: следите за выполнением блока кода, переходите к блоку catch, если найдено соответствующее исключение, или переходите непосредственно к блоку finally, если улова нет.
2. Блок кода перехвата: когда возникает соответствующее исключение, код внутри будет выполняться, либо обрабатываться, либо выбрасываться вверх.
3. Наконец, блок кода: он должен выполняться независимо от того, есть исключение или нет, обычно используется для очистки ресурсов, освобождения соединений и т. д. Однако есть несколько случаев, когда приведенный здесь код не будет выполняться.

  • Поток выполнения кода не входит в блок Try.
  • Код находится в состоянии бесконечного цикла, взаимоблокировки и т. д. в блоке кода попытки.
  • Операция System.exit() выполняется в блоке try.
попробовать/поймать/наконец ловушку

Вот две ловушки, с которыми мы можем столкнуться при использовании tcf.

код 1

public class TCFDemo {
    public static void main(String[] args) {
        //11
        System.out.println(returnVal());
    }

    static int returnVal(){
        int a = 1;
        int b = 10;
        try{
            return ++a;
        }finally {
            return ++b;
        }
    }
}

Ловушка 1: добавив, наконец, оператор return, он перезапишет возвращаемое значение попытки, если бизнес-логика более сложна, это очень легко поменять местами, но это не способствует устранению ошибки.

код 2

public class TCFDemo {
    public static void main(String[] args) {
        Lock lock = new ReentrantLock();
       try{
            //有可能加锁失败
            lock.lock();
            //dost
       }finally {
           lock.unlock();
       }
    }
}

Ловушка 2: Поскольку метод блокировки может генерировать исключение Uncheck при блокировке, если он находится в блоке кода try, неизбежно будет выполнен метод блокировки.В это время, поскольку блокировка не удалась, будет выброшено исключение IllegalMonitorStateException, поэтому что Последнее исключение покрывает информацию об исключении предыдущей ошибки блокировки, поэтому мы должны переместить метод блокировки за пределы блока кода попытки.

Лучшие практики

Что ж, я кратко представил классификацию исключений и меры предосторожности try/catch/finally Теперь мы можем обобщить наши «лучшие практики» в обработке исключений.

  1. Когда необходимо создать исключение, необходимо определить исключение, имеющее бизнес-значение, в соответствии с текущим бизнес-сценарием, и предпочтение отдается исключению, определенному в отрасли или в команде. Например, при использовании dubbo для тайм-аута вызова удаленной службы вместо непосредственного запуска RuntimeException будет выброшено исключение DubboTimeoutException.
  2. Не используйте оператор return в блоке finally, чтобы не усложнять оценку возвращаемого значения.
  3. Поймите исключение, специфичные подкатегории, а не исключение, но не бросаются. Это будет ловить все ошибки, в том числе серьезные ошибки, брошенные JVM, не могут обрабатывать.
  4. Помните, что нельзя игнорировать ни одно исключение (catch ничего не сделает), даже если вы можете гарантировать, что нормальная работа логики не пострадает, но никто не может гарантировать, как изменится код в будущем, не копайте отверстие для себя.
  5. Не используйте исключения для потока управления, это очень странная и требовательная к производительности практика.
  6. Операции, такие как очистка ресурсов и освобождение соединений, должны быть помещены в блок кода finally, чтобы предотвратить утечку памяти.Если блок finally обрабатывает больше логики и является модульным, мы можем инкапсулировать его в вызов метода инструмента, и код будет более кратким. .

конец

Маленькая аномалия, но большое знание, как вы думаете?

Публичный аккаунт "Программа Обезьяна в ночи" - Поделись самым галантереей
Категории