Код возврата при ошибке программы

  
 
     // Переводит строковое представление в численное
       Number  
     
         
         
         
               ParsingException
         
         
     

     // Переводит строковое представление в численное
            
     
        
         
     
 

 
    
  

    _loggerWarnexception

 
    

  

    exceptionErrorCode
    
         ErrorCodeMissingModifier
            
            
         ErrorCodeMissingBracket
            
            
        
            
    

 
    

    exceptionErrorCode  ErrorCodeMissingModifier

    

    exceptionErrorCode  ErrorCodeMissingBracket

    

  Main

    
    
        Foo
    
        Checkex
    
        
    


  Foo

    Boo


  Boo

      Exception


  Check 

     exMessage  

     
    
          
        
            
            
                ProxyRunnerGo
            
                Checkex
            
                
            
        

           
        
               AppDomainCurrentDomainFriendlyName // -> TestApp.exe
             exMessage  
        

            
        
              
            
                  Exception
            

               
            
                   AppDomainCreateDomain   AppDomainSetup
                
                      AppDomainCurrentDomainBaseDirectory
                
                   ProxyRunner domCreateInstanceAndUnwrapAssemblyFullName FullName
                proxyMethodInsideAppDomain
            
        
    

 

    
      

    
      


  Main

    
    
        ProxyRunnerGo
        ConsoleReadKey
    
        exWrappedException  Program
    
        
    


  Check 

       AppDomainCurrentDomainFriendlyName // -> TestApp.exe
     exMessage  


    

      
    
            Cast    Program
         xException
    

       
    
           AppDomainCreateDomain   AppDomainSetup
        
              AppDomainCurrentDomainBaseDirectory
        
           ProxyRunnerdomCreateInstanceAndUnwrapAssemblyFullName FullName
        proxyMethodInsideAppDomain
    

Зарегистрируйтесь для доступа к 15+ бесплатным курсам по программированию с тренажером

Обработка ошибок

Подход, при котором мы возвращаем либо false, либо данные, подразумевает, что у нас есть два состояния. Но это не всегда так.

Например, если мы возвращаем ошибку файловой системы, то обычно хотим знать, что за ошибка произошла. Например, в файловых системах в UNIXO количество ошибок превышает 100:

       /* Operation not permitted */
      /* No such file or directory */
       /* No such process */
       /* Interrupted system call */
         /* I/O error */
       /* No such device or address */
       /* Arg list too long */
     /* Exec format error */
       /* Bad file number */
     /* No child processes */

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

В этом случае появляется вопрос, как действовать — как возвращать результат. Один из самых простых вариантов — это коды возврата.

Коды возврата

Возврат ошибки связан с тем, что мы возвращаем не просто false или undefined. Мы возвращаем некоторое число. Оно говорит о том, какая ошибка произошла. Это работает так:

// Вызываем команду, например, удаление директории, и получаем результат
   

// Проверяем, является ли результат частью списка ошибок. Перечисляем возможные варианты
 /* errors list */ 
  
  
  

В итоге мы узнаем, входит ли результат в список ошибок. Если всё хорошо, то мы продолжаем работать и используем тот же результат.

Проблема в том, что результат иногда может быть числовым. Тогда нам нужно выбрать лист ошибок, чтобы нормальное значение не попадало в него.

В итоге нам постоянно придется делать такие проверки — проверять большое количество возможных возвратов. Такой процесс нужно упрощать.

Возврат результата в СИ

В Си принят следующий подход возврата результата:

  

  

   
    
  # Открываем файл на чтение
     
  # Делаем проверку
       // Value of errno is: 2
    # Если указатель равен нулю, то пишем, что произошла ошибка
     "Value of errno: %d 
    
     
  
   

Ошибка записывается в глобальную переменную, которая называется errno. И там, например, будет цифра 2, которая означает, что всё плохо.

Здесь мы убеждаемся, что у нас нет адекватного результата. Но по сути идет глобальное изменение среды. А глобальные переменные — это не вариант, особенно, в современных языках.

Возврат результата в Golang

Рассмотрим более продвинутый способ. Этот тот же способ, что и в СИ, но улучшенный. Он называется Golang Style.

Golang — это современный язык, который избавляет от глобальных переменных.

 
 
  
  
  


  
  // Возращается два значения: dat — данные, err — ошибка
     
  // Проверяем, равна ли ошибка nil
      
    
  
  

Если ошибка не равна nil, то ошибки нет, и всё хорошо. Если равна nil, то мы обрабатываем ее.

Это фактически такой же подход как в CИ. Только здесь нет глобальной переменной, которая постоянно меняется. Каждая функция возвращает свой результат выполнения. Так мы двигаемся вниз по вызовам и можем строить программу.

Возврат результата в JavaScript

В JavaScript можно использовать такой же подход. Это рабочая схема, которая основана на Destructuring. У нее есть определенные недостатки, которые мы разберем в следующем уроке.

// Делаем чтение, описываем данные и ошибку
    
    
  // do something with data
  
  // handle error

Если ошибка равна null, то делаем все что хотим, если нет, то обрабатываем ошибку.

Инструменты автоматизации и мониторинга удобны тем, что разработчик может взять готовые скрипты, при необходимости адаптировать и использовать в своём проекте. Можно заметить, что в некоторых скриптах используются коды завершения (exit codes), а в других нет. О коде завершения легко забыть, но это очень полезный инструмент. Особенно важно использовать его в скриптах командной строки.

Что такое коды завершения

В Linux и других Unix-подобных операционных системах программы во время завершения могут передавать значение родительскому процессу. Это значение называется кодом завершения или состоянием завершения. В POSIX по соглашению действует стандарт: программа передаёт 0 при успешном исполнении и 1 или большее число при неудачном исполнении.

Почему это важно? Если смотреть на коды завершения в контексте скриптов для командной строки, ответ очевиден. Любой полезный Bash-скрипт неизбежно будет использоваться в других скриптах или его обернут в однострочник Bash. Это особенно актуально при использовании инструментов автоматизации типа SaltStack или инструментов мониторинга типа Nagios. Эти программы исполняют скрипт и проверяют статус завершения, чтобы определить, было ли исполнение успешным.

Кроме того, даже если вы не определяете коды завершения, они всё равно есть в ваших скриптах. Но без корректного определения кодов выхода можно столкнуться с проблемами: ложными сообщениями об успешном исполнении, которые могут повлиять на работу скрипта.

Что происходит, когда коды завершения не определены

В Linux любой код, запущенный в командной строке, имеет код завершения. Если код завершения не определён, Bash-скрипты используют код выхода последней запущенной команды. Чтобы лучше понять суть, обратите внимание на пример.

 /root/test
created file

$ ./tmp.sh 
touch: cannot touch '/root/test': Permission denied
created file
$ echo $?
0

 /root/test

$ ./tmp.sh 
touch: cannot touch '/root/test': Permission denied
$ echo $?
1

Поскольку touch в данном случае — последняя запущенная команда, и она не выполнилась, получаем код возврата 1.

Как использовать коды завершения в Bash-скриптах

Проверяем коды завершения

Выше мы пользовались специальной переменной $?, чтобы получить код завершения скрипта. Также с помощью этой переменной можно проверить, выполнилась ли команда touch успешно.

 /root/test 2> /dev/null
    0 
 "Successfully created file"
 "Could not create file" &2

После рефакторинга скрипта получаем такое поведение:

• Если команда touch выполняется с кодом 0, скрипт с помощью echo сообщает об успешно созданном файле.
• Если команда touch выполняется с другим кодом, скрипт сообщает, что не смог создать файл.

$ ./tmp.sh
Could not create file

Создаём собственный код завершения

Наш скрипт уже сообщает об ошибке, если команда touch выполняется с ошибкой. Но в случае успешного выполнения команды мы всё также получаем код 0.

$ ./tmp.sh
Could not create file
$ echo $?
0

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

 /root/test 2> /dev/null
    0 
 "Successfully created file"
  0
 "Could not create file" &2
  1

$ ./tmp.sh
Could not create file
$ echo $?
1

Как использовать коды завершения в командной строке

Скрипт уже умеет сообщать пользователям и программам об успешном или неуспешном выполнении. Теперь его можно использовать с другими инструментами администрирования или однострочниками командной строки.

$ ./tmp.sh && echo "bam" || (sudo ./tmp.sh && echo "bam" || echo "fail")
Could not create file
Successfully created file
bam

Скрипт использует коды завершения, чтобы понять, была ли команда успешно выполнена. Если коды завершения используются некорректно, пользователь скрипта может получить неожиданные результаты при неудачном выполнении команды.

Дополнительные коды завершения

Команда exit принимает числа от 0 до 255. В большинстве случаев можно обойтись кодами 0 и 1. Однако есть зарезервированные коды, которые обозначают конкретные ошибки. Список зарезервированных кодов можно посмотреть в документации.

Адаптированный перевод статьи Understanding Exit Codes and how to use them in bash scripts by Benjamin Cane. Мнение администрации Хекслета может не совпадать с мнением автора оригинальной публикации.

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

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

Прежде чем начать, давайте разберемся с терминологией. В отличие от программы, библиотека не может использоваться напрямую, например, в терминале. Любая библиотека — это код на конкретном языке, который вызывается другим кодом на этом же языке. Говорят, что у библиотеки есть клиент. Клиент — тот, кто использует библиотеку:

// http-клиент в js, эту библиотеку мы будем использовать в качестве примера
   

// С точки зрения axios, этот файл содержит клиентский код
// То есть код, который использует axios.

      
     
  // Вызов библиотеки идет в клиентском коде
      
  

В свою очередь, находящийся внутри библиотеки код называется библиотечным кодом. Это разделение довольно важно, так как у каждой из этих частей своя зона ответственности.

Сами библиотеки часто реализованы как функция, набор функций, класс, или, опять же, набор классов. Обработка ошибок в этом случае различаться не будет, поэтому для простоты все примеры ниже будут построены на функциях.

Про ошибки

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

// Эта функция ищет символ в строке и возвращает его индекс
// Данный вызов ничего не найдет
 

Такое поведение нормально для данной функции. Если значения нет, все нормально, функция все равно выполнила свою задачу и вернула что-то осмысленное.

А что насчет http запроса как в примере выше? Как вести себя функции axios.get, которая не смогла загрузить указанную страницу? С точки зрения функции такая ситуация не является нормальной. Если функция не может выполнить свое основное предназначение, это ошибка. Именно об этих ошибках и пойдет речь. Ниже конкретные примеры того, как делать стоит и как не стоит при использовании библиотек и их проектировании.

Завершение процесса

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

 /* что-то не получилось */ 
  

Есть ровно одна причина, по которой такой код недопустим ни в одной библиотеке: то, что является фатальной ошибкой для конкретной библиотеки, не является такой же ошибкой для всей программы. В самом худшем случае программа предупредит пользователя о неудачной попытке загрузить сайт и попросит попробовать снова. Подобное поведение невозможно было бы реализовать в случае использования библиотеки, которая останавливает выполнение целой программы.

Проще говоря, библиотека не может решать за программу, когда ей завершаться. Это не ее зона ответственности. Задача библиотеки — оповестить клиентский код об ошибке, а дальше уже не ее забота. Оповещать можно с помощью исключений:

   

      
     
   
        
    // Делаем что-нибудь полезное с response
    
     
    // Для отладки хорошо бы вывести полную информацию
    
    // exit нужно делать на уровне программы,
    // так как важно установить правильный код возврата (отличный от 0)
    // только так снаружи можно будет понять что была ошибка
    
  

Вопрос на самоконтроль. Можно ли написать тесты на библиотеку, которая выполняет остановку процесса?

Имитация успеха

Иногда разработчик пытается скрыть от клиентского кода любые или почти любые ошибки. Код в таком случае перехватывает все возможные ошибки (исключения) и всегда возвращает какой-то результат. Ниже гипотетический пример с функцией axios.get. Как бы она выглядела в этом случае:

// Очень упрощенный код внутри axios.get
     
  // Тут на самом деле сложный асинхронный код, выполняющий http запрос
  // Опустим его и посмотрим на то место где возникает ошибка
  // Ниже упрощенный пример обработки ошибки
    
    // Генеральная идея — этот код возвращает какой-то результат,
    // который сложно или невозможно отличить от успешно выполненного запроса
          
     
  

Самая главная проблема в таком решении: оно скрывает проблемы и делает невозможным или практически невозможным отлов ошибки снаружи, в клиентском коде:

   

      
     
  // Как узнать что тут произошла ошибка и предупредить пользователя?
      
  

Правильное решение — использовать исключения.

Подавление ошибок

Этот способ очень похож на предыдущий. Код с подавлением ошибки выглядит примерно так:

// Очень упрощенный код внутри axios.get
     
    
    `Something was wrong during http request: 
     
  

Что здесь происходит? Разработчик выводит сообщение об ошибке в консоль и возвращает наружу, например, null. Такой код появляется тогда, когда программист еще не до конца осознал, что такое библиотека. Главный вопрос, который должен вызывать этот код: а как клиентский код узнает об ошибке? Ответ здесь — никак. Подобную библиотеку невозможно использовать правильно. Представьте, если бы так себя вел axios.get:

   

      
     
  // Во время ошибки идет вывод в консоль
  // А если консоли вообще нет?
  // Даже если есть, как обработать ошибку?
      
  

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

       

// Клиент этой функции (библиотеки) никогда не узнает о том, что произошла ошибка
      
   
        
     
     
    
     
     
  

Правильное решение — порождать исключения и не подавлять исключения.

Коды возврата

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

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

Исключения

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

  
    /* чем больше тут полезной информации, тем лучше */

Методы обработки ошибок

1. Не обрабатывать.

2. Коды возврата. Основная идея — в случае ошибки возвращать специальное значение, которое не может быть корректным. Например, если в методе есть операция деления, то придется проверять делитель на равенство нулю. Также проверим корректность аргументов a и b:

Double f(Double a, Double b) {
     ((a == ) || (b == )) {
        ;
    }
    
     (Math.abs(b) < ) {
        ;    
    }  {
         a / b;
    }
}

При вызове метода необходимо проверить возвращаемое значение:

Double d = f(a, b); 
 (d != ) {
    
}  {
    
}

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

3.Использовать флаг ошибки: при возникновении ошибки устанавливать флаг в соответствующее значение:

 ;

Double f(Double a, Double b) {
     ((a == ) || (b == )) {
         = ;
        ;
    }
    
     (Math.abs(b) < ) {
         = ;
         b;    
    }  {
         a / b;
    }
}

 = ;
Double d = f(a, b); 
 () {
    
}  {
    
} 

Минусы такого подхода аналогичны минусам использования кодов возврата.

4.Можно вызвать метод обработки ошибки и возвращать то, что вернет этот метод.

Double f(Double a, Double b) {
      ((a == ) || (b == )) {
          nullPointer();
     }
     
      (Math.abs(b) < ) {
          divisionByZero();    
     }  {
          a / b;
     }
 }

Но в таком случае не всегда возможно проверить корректность результата вызова основного метода.

5.В случае ошибки просто закрыть программу.

 (Math.abs(b) < ) {
    System.exit();
    ;    
}

Это приведет к потере данных, также невозможно понять, в каком месте возникла ошибка.

Исключения

В Java возможна обработка ошибок с помощью исключений:

Double f(Double a, Double b) {
     ((a == ) || (b == )) {
         IllegalArgumentException("arguments of f() are null");
    }
    
     a / b;
}

Проверять b на равенство нулю уже нет необходимости, так как при делении на ноль метод бросит непроверяемое исключение ArithmeticException.

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

Каждый раз, когда при выполнении программы происходит ошибка, создается объект-исключение, содержащий информацию об ошибке, включая её тип и состояние программы на момент возникновения ошибки.
После создания исключения среда выполнения пытается найти в стеке вызовов метод, который содержит код, обрабатывающий это исключение. Поиск начинается с метода, в котором произошла ошибка, и проходит через стек в обратном порядке вызова методов. Если не было найдено ни одного подходящего обработчика, выполнение программы завершается.

Таким образом, механизм обработки исключений содержит следующие операции:

1. Создание объекта-исключения.
2. Заполнение stack trace’а этого исключения.
3. Stack unwinding (раскрутка стека) в поисках нужного обработчика.

Классификация исключений

Класс Java Throwable описывает все, что может быть брошено как исключение. Наследеники Throwable — Exception и Error — основные типы исключений. Также RuntimeException, унаследованный от Exception, является существенным классом.

Иерархия стандартных исключений

Наследники класса Exception (кроме наслеников RuntimeException) являются проверяемыми исключениями(checked exception). Как правило, это ошибки, возникшие по вине внешних обстоятельств или пользователя приложения – неправильно указали имя файла, например. Эти исключения должны обрабатываться в ходе работы программы, поэтому компилятор проверяет наличие обработчика или явного описания тех типов исключений, которые могут быть сгенерированы некоторым методом.

Все исключения, кроме классов Error и RuntimeException и их наследников, являются проверяемыми.

Класс Error и его подклассы предназначены для системных ошибок. Свои собственные классы-наследники для Error писать (за очень редкими исключениями) не нужно. Как правило, это действительно фатальные ошибки, пытаться обработать которые довольно бессмысленно (например OutOfMemoryError).

Эти исключения обычно возникают в результате ошибок программирования, такие как ошибки разработчика или неверное использование интерфейса приложения. Например, в случае выхода за границы массива метод бросит OutOfBoundsException. Такие ошибки могут быть в любом месте программы, поэтому компилятор не требует указывать runtime исключения в объявлении метода. Теоретически приложение может поймать это исключение, но разумнее исправить ошибку.

Обработка исключений

Чтобы сгенерировать исключение используется ключевое слово throw. Как и любой объект в Java, исключения создаются с помощью new.

 (t == ) {
     NullPointerException("t = null");
}

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

Возможна ситуация, когда одно исключение становится причиной другого. Для этого существует механизм exception chaining. Практически у каждого класса исключения есть конструктор, принимающий в качестве параметра Throwable – причину исключительной ситуации. Если же такого конструктора нет, то у Throwable есть метод initCause(Throwable), который можно вызвать один раз, и передать ему исключение-причину.

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

 f()  InterruptedException, IOException { 

Код, который может бросить исключения оборачивается в try-блок, после которого идут блоки catch и finally (Один из них может быть опущен).

 {
    // Код, который может сгенерировать исключение
}

Сразу после блока проверки следуют обработчики исключений, которые объявляются ключевым словом catch.

 {
    // Код, который может сгенерировать исключение
} (Type1 id1) {
    // Обработка исключения Type1
} (Type2 id2) {
    // Обработка исключения Type2
}

Сatch-блоки обрабатывают исключения, указанные в качестве аргумента. Тип аргумента должен быть классом, унаследованного от Throwable, или самим Throwable. Блок catch выполняется, если тип брошенного исключения является наследником типа аргумента и если это исключение не было обработано предыдущими блоками.

Код из блока finally выполнится в любом случае: при нормальном выходе из try, после обработки исключения или при выходе по команде return.

NB: Если JVM выйдет во время выполнения кода из try или catch, то finally-блок может не выполниться. Также, например, если поток выполняющий try или catch код остановлен, то блок finally может не выполниться, даже если приложение продолжает работать.

Блок finally удобен для закрытия файлов и освобождения любых других ресурсов. Код в блоке finally должен быть максимально простым. Если внутри блока finally будет брошено какое-либо исключение или просто встретится оператор return, брошенное в блоке try исключение (если таковое было брошено) будет забыто.

 java.io.IOException;

 ExceptionTest {
   
    public static void main(String[] args) {
         {
             {
                Exception();
            }  {
                 IOException();
            }
        }  (IOException ex) {
            System..println(ex.getMessage());
        }  (Exception ex) {
            System..println(ex.getMessage());
        }
    }
}

После того, как было брошено первое исключение — new Exception("a") — будет выполнен блок finally, в котором будет брошено исключение new IOException("b"), именно оно будет поймано и обработано. Результатом его выполнения будет вывод в консоль b. Исходное исключение теряется.

Обработка исключений, вызвавших завершение потока

При использовании нескольких потоков бывают ситуации, когда поток завершается из-за исключения. Для того, чтобы определить с каким именно, начиная с версии Java 5 существует интерфейс Thread.UncaughtExceptionHandler. Его реализацию можно установить нужному потоку с помощью метода setUncaughtExceptionHandler. Можно также установить обработчик по умолчанию с помощью статического метода Thread.setDefaultUncaughtExceptionHandler.

Интерфейс Thread.UncaughtExceptionHandler имеет единственный метод uncaughtException(Thread t, Throwable e), в который передается экземпляр потока, завершившегося исключением, и экземпляр самого исключения. Когда поток завершается из-за непойманного исключения, JVM запрашивает у потока UncaughtExceptionHandler, используя метод Thread.getUncaughtExceptionHandler(), и вызвает метод обработчика – uncaughtException(Thread t, Throwable e). Все исключения, брошенные этим методом, игнорируются JVM.

Информация об исключениях

• getMessage(). Этот метод возвращает строку, которая была первым параметром при создании исключения;
• getCause() возвращает исключение, которое стало причиной текущего исключения;
• printStackTrace() печатает stack trace, который содержит информацию, с помощью которой можно определить причину исключения и место, где оно было брошено.

Exception in thread "main" java.lang.IllegalStateException: A book has a null property
        at com.example.myproject.Author.getBookIds(Author.java:38)
        at com.example.myproject.Bootstrap.main(Bootstrap.java:14)
Caused by: java.lang.NullPointerException
        at com.example.myproject.Book.getId(Book.java:22)
        at com.example.myproject.Author.getBookIds(Author.java:35)

Все методы выводятся в обратном порядке вызовов. В примере исключение IllegalStateException было брошено в методе getBookIds, который был вызван в main. «Caused by» означает, что исключение NullPointerException является причиной IllegalStateException.

Разработка исключений

Чтобы определить собственное проверяемое исключение, необходимо создать наследника класса java.lang.Exception. Желательно, чтобы у исключения был конструкор, которому можно передать сообщение:

 FooException  Exception {
     FooException() {
        ();
    }
     FooException(String message) {
        (message);
    }
     FooException(String message, Throwable cause) {
        (message, cause);
    }
     FooException(Throwable cause) {
        (cause);
    }
}

Исключения в Java7

• обработка нескольких типов исключений в одном catch-блоке:

 (IOException | SQLException ex) {...}

В таких случаях параметры неявно являются final, поэтому нельзя присвоить им другое значение в блоке catch.

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

• Try с ресурсами позволяет прямо в try-блоке объявлять необходимые ресурсы, которые по завершению блока будут корректно закрыты (с помощью метода close()). Любой объект реализующий java.lang.AutoCloseable может быть использован как ресурс.

 String readFirstLineFromFile(String path)  IOException {
     (BufferedReader br =
                    BufferedReader( FileReader(path))) {
         br.readLine();
    }
}

В приведенном примере в качестве ресурса использутся объект класса BufferedReader, который будет закрыт вне зависимосити от того, как выполнится try-блок.

Можно объявлять несколько ресурсов, разделяя их точкой с запятой:

public static void viewTable(Connection con) throws SQLException {
    
    String query = "select COF_NAME, SUP_ID, PRICE, SALES, TOTAL from COFFEES";
    
     (Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery(query)) {
        //Work with Statement and ResultSet
    }  (SQLException e) {
        e.printStackTrace;
    }
}

Во время закрытия ресурсов тоже может быть брошено исключение. В try-with-resources добавленна возможность хранения «подавленных» исключений, и брошенное try-блоком исключение имеет больший приоритет, чем исключения получившиеся во время закрытия. Получить последние можно вызовом метода getSuppressed() от исключения брошенного try-блоком.

• Перебрасывание исключений с улучшенной проверкой соответствия типов.

Компилятор Java SE 7 тщательнее анализирует перебрасываемые исключения. Рассмотрим следующий пример:

  FirstException  Exception { }
  SecondException  Exception { }
 
  rethrowException(String exceptionName)  Exception {
      {
          (.equals(exceptionName)) {
              FirstException();
         }  {
              SecondException();
         }
     }  (Exception ex) {
          e;
     }
 }

В примере try-блок может бросить либо FirstException, либо SecondException. В версиях до Java SE 7 невозможно указать эти исключения в декларации метода, потому что catch-блок перебрасывает исключение ex, тип которого — Exception.

В Java SE 7 вы можете указать, что метод rethrowException бросает только FirstException и SecondException. Компилятор определит, что исключение Exception ex могло возникнуть только в try-блоке, в котором может быть брошено FirstException или SecondException. Даже если тип параметра catch — Exception, компилятор определит, что это экземпляр либо FirstException, либо SecondException:

  rethrowException(String exceptionName)  FirstException, SecondException {
      {
         
     }  (Exception e) {
          e;
     }
 }

Если FirstException и SecondException не являются наследниками Exception, то необходимо указать и Exception в объявлении метода.

Примеры исключений

• любая операция может бросить VirtualMachineError. Как правило это происходит в результате системных сбоев.
• OutOfMemoryError. Приложение может бросить это исключение, если, например, не хватает места в куче, или не хватает памяти для того, чтобы создать стек нового потока.
• IllegalArgumentException используется для того, чтобы избежать передачи некорректных значений аргументов. Например:

 f(Object a) {  
     (a == ) {  
         IllegalArgumentException("a must not be null");  
    }  
}  

• IllegalStateException возникает в результате некорректного состояния объекта. Например, использование объекта перед тем как он будет инициализирован.

Гарантии безопасности

При возникновении исключительной ситуации, состояния объектов и программы могут удовлетворять некоторым условиям, которые определяются различными типами гарантий безопасности:

• Отсутствие гарантий (no exceptional safety). Если было брошено исключение, то не гарантируется, что все ресурсы будут корректно закрыты и что объекты, методы которых бросили исключения, могут в дальнейшем использоваться. Пользователю придется пересоздавать все необходимые объекты и он не может быть уверен в том, что может переиспозовать те же самые ресурсы.
• Отсутствие утечек (no-leak guarantee). Объект, даже если какой-нибудь его метод бросает исключение, освобождает все ресурсы или предоставляет способ сделать это.
• Слабые гарантии (weak exceptional safety). Если объект бросил исключение, то он находится в корректном состоянии, и все инварианты сохранены. Рассмотрим пример:

 Interval {
    //invariant: left <= right
    
    double left;
    double right;
    
}

Если будет брошено исключение в этом классе, то тогда гарантируется, что ивариант «левая граница интервала меньше правой» сохранится, но значения left и right могли измениться.

• Сильные гарантии (strong exceptional safety). Если при выполнении операции возникает исключение, то это не должно оказать какого-либо влияния на состояние приложения. Состояние объектов должно быть таким же как и до вызовов методов.

• Гарантия отсутствия исключений (no throw guarantee). Ни при каких обстоятельствах метод не должен генерировать исключения. В Java это невозможно, например, из-за того, что VirtualMachineError может произойти в любом месте, и это никак не зависит от кода. Кроме того, эту гарантию практически невозможно обеспечить в общем случае.