Что является 'исключительным'? [закрытый]

Это исключение, если:

1. Это состояние отказа. И

2. Это случается нечасто и неожиданно. И

3. Нет лучшего механизма для сообщая об этом.

править

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

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

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

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

4. При использовании исключений в надежном код, каждый метод должен улавливать неожиданные исключения и оберните их внутри исключения из договор. Другими словами, если ваш метод не обещает бросить NullReferenceException, вам необходимо поймать и бросить внутрь что-то более общее или конкретное. Они называются исключениями, а не сюрпризы!

Общее практическое правило:

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

Лично я считаю, что такого рода обсуждения - пустая трата времени и что «что является исключительным» - неправильный вопрос.

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

Правильный ли это выбор не должен определяться его названием. Были бы у нас эти дискуссии, если бы исключения назывались просто «пузырями»?

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

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

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

Пример плохого кода:

float x;
try {
x = a / b;
{
catch (System.DivideByZeoException) {
x = 0;
}

Хороший пример кода:

if (b == 0)
return 0;

Исключения обычно дороги.

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

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

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

Оно слишком круглое и круглое?: D

Лучшее обсуждение этого, что я видел, находится в блоге Дэна Вайнреба: Какие условия (исключения) действительно существуют .

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

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

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

Да, можно передавать обратно коды ошибок, но будут ли они использоваться? Я вижу много выделений памяти в C без проверки на NULL, и printfs, которые просто отбрасывают возвращаемое значение. Более того, многие функции не имеют различимого кода ошибки, например, отрицательный для printf и NULL для выделения памяти. Там, где любое возвращаемое значение может быть допустимым, необходимо найти способ вернуть признак ошибки, а это приводит к большим сложностям, чем большинство программистов готовы иметь дело. Исключение нельзя игнорировать, и оно не требует большого количества защитного кода.

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

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

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

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

Oracle, в контексте Java, определяет исключительное событие следующим образом:

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

Конечно, это определение применимо к исключениям вообще, а не только в Java.

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

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

Я считаю, что существует два вида исключений:

1. Баги, которые вносятся в программу программистом.
2. Неконтролируемые ситуации, как кто-то сказал, выдергивание вилки из розетки. Конечно, в этом случае программа не может выбросить исключение, но если бы могла, то выбросила бы. Другими исключениями могут быть какие-то сбои в ОС или сети, на которые полагается программа.

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

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

Два основных случая:

1. Когда вызывающий код просит вас сделать что-то неразумное.
2. Когда внешние зависимости оставили вам нечего делать.

В первом случае рассмотрим метод int IntegerDivide (int divisor, int divisor) . Теперь мы все знаем, что сами должны улавливать такие условия, как деление на ноль. Однако, если вызывающий код попросил этот метод разделить на ноль, уже слишком поздно - это не наш код решает делить на ноль, это вызывающий код. Единственное, что здесь можно сделать - это выбросить исключение.

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

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

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

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