Конвенции для исключений или коды ошибок

Коды ошибки также не работают, когда Ваш метод возвращает что-либо кроме числового значения...

В высокоуровневом материале, исключениях; в материале низкого уровня, кодах ошибки.

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

, Если, однако, я пишу часть кода, из которого я должен знать поведение в каждой возможной ситуации, тогда я хочу коды ошибки. Иначе я должен знать каждое исключение, которое может быть выдано каждой строкой в моей функции для знания то, что это сделает (Read Исключение, Которое Основанный Авиакомпания для понимания то, насколько хитрый это). Это утомительно и твердо записать код, который реагирует соответственно на каждую ситуацию (включая несчастные), но поэтому запись безошибочного кода утомительна и трудна, не потому что Вы передаете коды ошибки.

И Raymond Chen и Joel привели некоторые красноречивые аргументы против использования исключений для всего.

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

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

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

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

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

, Но вход в другое направление, использование Исключений позволяет Вам создавать еще высокоуровневые абстракции к своей обработке ошибок, которая может сделать Ваш код еще более выразительным и естественным. Я настоятельно рекомендовал бы чтение этого превосходного, все же недооцененный, статья эксперта по C++ Andrei Alexandrescu на предмет того, что он называет, "Осуществления": http://www.ddj.com/cpp/184403864 . Хотя это - статья C++, принципы вообще применимы, и я перевел понятие осуществлений в C# вполне успешно.

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

Во всех других случаях, исключениями является, вероятно, способ пойти.

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

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

А Простой Пример в Java:

public class DataValidationException extends Exception {


    private DataValidation error;

    /**
     * 
     */
    DataValidationException(DataValidation dataValidation) {
        super();
        this.error = dataValidation;
    }


}

enum DataValidation{

    TOO_SMALL(1,"The input is too small"),

    TOO_LARGE(2,"The input is too large");


    private DataValidation(int code, String input) {
        this.input = input;
        this.code = code;
    }

    private String input;

    private int code;

}

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

Так как я работаю с C++ и имею RAII для создания их безопасными использовать, я использую исключения почти исключительно. Это вытаскивает обработку ошибок из нормального процесса выполнения программы и делает намерение более ясным.

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

Сигнатуры методов должны передать Вам, что делает метод. Что-то как длинный errorCode = getErrorCode (); мог бы быть прекрасным, но длинный errorCode = fetchRecord (); сбивает с толку.

В прошлом я присоединился, errorcode лагерь (сделал слишком много C, программирующий). Но теперь я видел свет.

Да исключениями является определенная нагрузка в системе. Но они упрощают код, сокращая количество ошибок (и WTF's).

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

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

Я могу сидеть на заборе здесь, но...

1. Это зависит от языка.
2. , Какой бы ни модель Вы выбираете, быть последовательными о том, как Вы используете ее.

В Python, использование исключений является общепринятой практикой, и я довольно рад определить свои собственные исключения. В C у Вас нет исключений вообще.

В C++ (в STL, по крайней мере), исключения обычно только выдаются для действительно исключительных ошибок (я фактически никогда не вижу их сам). Я не вижу оснований, чтобы сделать что-либо различное в моем собственном коде. Да легко проигнорировать возвращаемые значения, но C++ не вынуждает Вас поймать исключения также. Я думаю, что просто необходимо выработать привычку выполнения его.

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

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

Вот некоторое обсуждение статей, сравнение и контрастирование этих двух методов:

• Объектно-ориентированная Обработка исключений в исключениях Perl
• по сравнению с возвратами состояния

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

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

Исключения для "чего-либо, что останавливает или запрещает методу или подпрограмме выполнение, что Вы попросили, чтобы он сделал"... НЕ пасовать назад сообщения о неисправностях или необычных обстоятельствах или состоянии системы, и т.д. Используйте возвращаемые значения или касательно (или) параметры для этого.

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

Employee EmpOfMonth = GetEmployeeOfTheMonth();

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

Employee EmpOfMonth; 
if (getEmployeeOfTheMonth(ref EmpOfMonth) == ERROR)
    // code to Handle the error here

, Если Вы кодируете так, чтобы каждый метод сделал одну и только одну простую вещь, тогда необходимо выдать исключение каждый раз, когда метод не может выполнить желаемую цель метода. Исключения намного более богаты и легче использовать таким образом, чем коды ошибки. Ваш код является намного более чистым - стандартный поток "нормального" пути выполнения кода может быть посвящен строго случаю, где метод В СОСТОЯНИИ выполнить то, что Вы хотели, чтобы он сделал... И затем код, чтобы вымыться, или обработать "исключительные" обстоятельства, когда что-то плохо происходит, который препятствует тому, чтобы метод завершился успешно, может быть siloed далеко от нормального кода. Кроме того, если Вы не можете обработать исключение, где оно произошло и должно передать его стек к UI, (или хуже, через провод от середины уровневого компонента к UI), затем с моделью исключения, Вы не должны кодировать каждый прошедший метод в своем стеке, чтобы распознать и передать исключение стек... Модель исключения делает это для Вас автоволшебно.... С кодами ошибки эта часть загадки может стать обременительной очень быстро.

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

Я предпочитаю исключения, потому что

• они прерывают поток логики
• , они извлекают выгоду из иерархии классов, которая дает больше функций/функциональности
• , когда используется, правильно может представить широкий спектр ошибок (например, InvalidMethodCallException является также LogicException, поскольку оба происходят, когда существует ошибка в Вашем коде, который должен быть обнаруживаемым перед временем выполнения), и
• они могут использоваться для улучшения ошибки (т.е. определение класса FileReadException может тогда содержать код, чтобы проверить, существует ли файл или заблокирован, и т.д.)