Почему Исключения, как говорят, так плохи для Контроля ввода?

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

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

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

public bool isValidDate(string date)
{
    bool retVal = true;
    //check for 4 digit year
    throw new FourDigitYearRequiredException();
    retVal = false;

    //check for leap years
    throw new NoFeb29InANonLeapYearException();
    retVal = false;
    return retVal;
}

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

public bool isValidDate(string date)
{
    bool retVal = false;
    retVal = doesDateContainAFourDigitYear(date);
    retVal = isDateInALeapYear(date);
    return retVal;
}

public bool isDateInALeapYear(string date){}

public bool doesDateContainAFourDigitYear(string date){}

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

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

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

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

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

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

Другое голосование против обработки исключений для вещей, которые не являются исключениями!

1. В.NET JIT-компилятор не выполнит оптимизацию в определенных случаях, даже когда исключения не выдаются. Следующие статьи объясняют его хорошо. http://msmvps.com/blogs/peterritchie/archive/2007/06/22/performance-implications-of-try-catch-finally.aspx http://msmvps.com/blogs/peterritchie/archive/2007/07/12/performance-implications-of-try-catch-finally-part-two.aspx

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

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

существуют проблемы производительности за исключениями, но в коде GUI Вы не должны будете обычно волноваться о них. Таким образом, что, если проверка берет дополнительные 100 мс для выполнения? Пользователь не собирается замечать это.

До некоторой степени это - непростое решение - С одной стороны, Вы не могли бы хотеть обрушиваться свое целое приложение, потому что пользователь ввел дополнительную цифру в текстовое поле почтового индекса, и Вы забыли обрабатывать исключение. На другом, 'сбой рано, сбой трудно' подход гарантирует, что ошибки обнаружены и зафиксировали быстро и сохраняют Вашу драгоценную базу данных нормальной. В целом я думаю, что большинство платформ рекомендует не использовать обработку исключений для проверки ошибок UI, и некоторые, как.NET Windows Forms, обеспечивают хорошие способы сделать это (события ErrorProviders и Validation) без исключений.

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

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

вход не то, что ожидалось и следовательно исключительное.

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

Выдача исключения позволяет мне определять точно, что неправильно было похоже на StringValueTooLong или или IntegerValueTooLow или InvalidDateValue или что бы то ни было. Почему это считают неправильным?

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

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

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

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

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

при кодировании сервера на протокольном уровне Вы могли бы обоснованно ожидать, что клиент проверит ввод данных пользователем. Снова, недопустимый вход здесь действительно был бы исключением. Это очень отличается от доверия клиенту 100% (который был бы очень глуп действительно) - но в отличие от прямого ввода данных пользователем, Вы предсказываете, что большую часть времени исходные данные были бы в порядке. Строки размываются здесь несколько. Чем более вероятно случается так, что что-то происходит, тем меньше Вы хотите использовать исключения для обработки его.

1. Пригодность для обслуживания - Исключения создают нечетные пути выполнения кода, мало чем отличаясь от GOTOs.
2. Простота использования (для других классов) - Другие классы могут положить, что исключениями, повышенными от Вашего класса ввода данных пользователем, являются фактические ошибки
3. Производительность - На большинстве языков, исключение подвергается штрафу производительности и использования памяти.
4. Семантика - значение слов действительно имеет значение. Плохой вход не является "исключительным".

Я думаю, что различие зависит от контракта конкретного класса, т.е.

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

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

Уже существует один важен другая причина, чем те упомянутые:

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