Что принципы ведут Вашу политику обработки исключений? [закрытый]

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

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

При рассмотрении исключений (в C++, по крайней мере) необходимо полагать, что исключение гарантирует, что API делает. Минимальный уровень гарантии должен быть Основной гарантией, хотя необходимо стремиться (где соответствующий) обеспечить сильную гарантию. В случаях, откуда Вы не используете внешних зависимостей суставного API, можно даже попытаться не обеспечить гарантию броска.

N.B. не путают гарантии исключения со спецификациями исключения.

Гарантии Исключения:

Никакая Гарантия:

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

Основная Гарантия:

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

Сильная Гарантия: (иначе Транзакционная Гарантия)

Это гарантирует, что метод будет полностью успешно, Или Исключение будет выдано, и состояние объектов не изменится.

Никакая Гарантия Броска:

метод гарантирует, что никаким исключениям не позволяют распространить из метода. Все деструкторы должны сделать эту гарантию.
| N.B. Если исключение выйдет из деструктора, в то время как исключение уже распространяет
|, то приложение завершится

Эта запись в блоге от Eric Lippert, Главного Инженера-разработчика программного обеспечения в Microsoft, подводит итог превосходного и краткого набора инструкции .

Короче говоря:

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

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

• Досаждать : Относительно простые ошибки, которые кодируют Вас, не владеют, бросает в Вас. Необходимо поймать все их и соглашение с ними, обычно таким же образом, поскольку Вы имели бы дело с Глупый собственное исключение. Не бросайте их назад снова. Пример: исключение Формата из C# Int32. Синтаксический анализ () метод

• Внешний : Относительно простые ошибки, которые много походят Досаждать (от кода других людей) или даже Глупый (от Вашего кода) ситуации, но должны быть брошены, потому что действительность диктует, что код это бросает их действительно, понятия не имеют, как восстановиться, но вызывающая сторона, вероятно, будет. Разрешение и бросок они, но когда Ваш код получает их откуда-либо, ловят их и соглашение с ними. Пример: Файл, не найденный исключением.

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

1. Никогда не выдают исключения от деструкторов.

2. Поддерживают некоторый базовый уровень гарантий исключения о состоянии объекта.

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

4. не выдают исключения, если можно помочь ему. Это замедляет все.

5. не Делают всего catch(...) и ничего не делают. Исключения выгоды Вы знаете об или определенные исключения. По крайней мере зарегистрируйте то, что произошло.

6. , Когда в исключении мир используют RAII, потому что ничто больше не безопасно.

7. Поставлющийся код не должен был подавлять исключения, по крайней мере, относительно памяти.

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

9. Знают о флагах, которые могут заставить библиотеки как STL выдавать исключения вместо того, чтобы показать неизвестное поведение (например, недопустимые итераторы / векторное нижнее переполнение).

10. ссылки Выгоды вместо копий объекта исключения?

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

12. , Если код выдает исключение, больше чем 2% времени считают создание его кодом ошибки для пользы производительности.

13. Рассматривают не выдавание исключения от неукрашенного экспорта dll / C интерфейсы, потому что некоторые компиляторы оптимизируют, предполагая C, что код не выдает исключения.

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

    main 
    {
         try {
        all code....
        }
        catch(...) {} 
    }
    

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

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

я - разработчик.NET, и для выгоды и броска, мой подход:

1. Только попытка/выгода в открытых методах (в целом; очевидно, если бы Вы захватываете для определенной ошибки, Вы проверили бы на нее там)
2. , Только входят в систему уровень UI прямо прежде, чем подавить ошибку и перенаправить к ошибочной странице/форме.

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

Исключения Доступа

• Создание или соединение с любым видом соединения (удаленный, локальный).
  • Происходит в: Базы данных, Дистанционная работа
  • Причины: не существующий, Уже используемые или Недоступные, Недостаточные/Недопустимые Учетные данные
• Открытие, Чтение или Запись в любой вид ресурса
  • Происходят в: Файловый ввод-вывод, База данных
  • Причины: Заблокированные, Недоступные, Недостаточные/Недопустимые учетные данные

Целостность Данных

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

Законность Данных

• действительно ли это - корректные обеспеченные данные? (Это находится в правильном формате, но это не мог бы быть корректный набор параметров для данной ситуации)
  • , Происходит в: Запросы Базы данных, Транзакции, веб-сервисы
  • Пример: Представление строки к базе данных и нарушению ограничения

, Очевидно, существует другие случаи, но они обычно - те, я пытаюсь соблюдать где его необходимое.

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

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

, Как отмечено другим комментатором, необходимо также избегать использования исключений для обработки ожидаемых условий, которые можно ожидать и избежать. Например, в платформе.NET, интервале. TryParse предпочтителен для международного Синтаксического анализа с попыткой/выгодой, особенно, когда используется в цикле или таком.

эта статья от BEA (теперь оракул) является хорошей выставкой о том, как пойти об этом: http://www.oracle.com/technology/pub/articles/dev2arch/2006/11/effective-exceptions.html . Это отчасти принимает Java, но необходимо быть в состоянии использовать его для других сред также.

Как разработчик C++, моя собственная политика не состоит в том, чтобы выдать исключения от того, что я считаю общедоступной пчелой к своим классам/модулям (на самом деле, требование с COM). Однако я использую исключения экстенсивно в частной реализации класса. Например, работа с ATL:

HRESULT Foo()
{
    HRESULT hr = S_OK;
    try {
        // Avoid a whole lot of nested ifs and return code
        // checking - internal stuff just throws.
        DoStuff();
        DoMoreStuff(); // etc.
    } catch ( CAtlException& e ) {
        hr = e;
    }
    return hr;
}

void DoSomething()
{
    // If something goes wrong, AtlThrow( E_FAILED or E_WHATEVER ); 
}

Не исключения, повышенные языковой средой в соответствии со спецификацией. из языка, используемого, если действительно это действительно имеет понятие исключений? Я думаю, "делятся на нуль" в Java или CONSTRAINT_ERROR в Ada по сравнению ни с чем вообще в C.

, Как программист может "решить" использовать исключения после выбора языка программирования, который исключения определили в его составе?

Редактирование: Или вместо того, чтобы "использовать" исключения, Вы имеете в виду, когда иметь связную и последовательную политику об "обработке" исключений?

Edit2: Вы хотели бы проверять бесплатная глава из книги Steven Dewhurst "Глюки C++", конкретно Глюк 64 и Глюк 65. Хотя это фокусируется на C++, включенные уроки полезны на других языках.

Контекст этот ответ сдан, является языком Java.

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

Однако мы не бросаем контролируемые исключительные ситуации, никогда. Мы разделяем RuntimeException на подклассы для наших собственных определенных исключений, ловя их когда это применимо непосредственно, и что касается исключений, которые выдаются другими библиотеками, API JDK, и т.д., мы действительно пробуем/ловим внутренне и любой журнал исключение (если что-то произошло, который действительно не должен иметь, и у Вас нет способа восстановиться как файл, не найденный исключением для пакетного задания), или мы обертываем исключение в RuntimeException и затем бросаем его. За пределами кода мы полагаемся на обработчик исключений, чтобы в конечном счете поймать тот RuntimeException, быть что JVM или веб-контейнер.

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

Я считаю, что лучший способ использования исключений зависит от того, какой компьютерный язык вы используете. Например, Java имеет гораздо более надежную реализацию исключений, чем C ++.

Если вы используете C ++, я рекомендую вам хотя бы попытаться прочитать, что Бьярн Страуструп (изобретатель C ++) может сказать о безопасности исключений. См. приложение E к его книге «Язык программирования C ++».

Он тратит 34 страницы, пытаясь объяснить, как работать с исключениями безопасным способом. Если вы понимаете его совет, то это все, что вам нужно знать.

С моей политикой обработки исключений можно ознакомиться по адресу:

http://henko.net/imperfection/exception-handling-policy-throwing-exception/ .

(Надеюсь, продвижение веб-сайта не противоречит правилам, но это слишком много информации, чтобы вставить сюда.)