Там какая-либо причина состоит в том, чтобы бросить DivideByZeroException?

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

В настоящий момент я не могу придумать вескую причину, чтобы бросить NullReferenceException. Если вы создаете API с документацией, которая гласит: «Первый параметр HummingBirdFeeder.OpenSugarWaterDispenser(Dispenser dispenser, int flowRate) - это дозатор сахарной воды, который вы хотите открыть». И если затем кто-то придет и передаст нулевое значение этому методу, то вам обязательно следует бросить ArgumentNullException.

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

ИЗМЕНЕНО ДЛЯ ДОБАВЛЕНИЯ:

Теперь, когда вы изменили вопрос, чтобы сослаться на ArgumentNullException, тогда ответ прост: да, вы должны определенно выбросить такого рода исключения при следующих обстоятельствах:

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

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

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

Debug.Assert(dispenser != null);

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

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

Однако вы можете избежать многих из этих исключений, просматривая значения, передаваемые клиентским кодом. Вам понадобится ArgumentNullException с именем аргумента, если клиентский код передал значение NULL, ArgumentException, когда он передал что-то, что может отключить DivideByZero.

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

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

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

Учтите, что для удвоений деление на ноль фактически приведет к значению: double.Infinity, double.NegativeInfinity или double.NaN, в зависимости от того, числитель положительный, отрицательный или ноль соответственно.

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

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

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

Следует ли мне использовать исключения при проверке пользовательского ввода?

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

Однако при проверке «данных» на более глубоких уровнях приложения генерация исключения обычно является правильным решением.

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

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

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

По крайней мере, так мне сказал мой старший разработчик, когда я пытался поймать DivideByZeroException много месяцев назад.

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

Если вы писали числовой класс некоторой формы и могли ожидать, что код, вызывающий ваш класс, выполнил проверку, тогда я вижу, что может быть полезно throw DivisionByZeroException, но почти в любом другом случае лучше проверить перед операцией и выбросить исключение ArgumentException или ArgumentOutOfRange в зависимости от ситуации.

NullReferenceException - одно из зарезервированных исключений, используемых платформой, которое вы никогда не должны передавать через общедоступный API, наряду с IndexOutOfRange, AccessViolationException и OutOfMemoryException. См. Книгу Руководства по проектированию Framework или объяснение предупреждения Code Analysis

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

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

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

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

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

Krzysztof Cwalina, Designing Reusable Frameworks

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

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

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

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

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

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

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