Выдача исключения по сравнению с проверкой пустого указателя, для нулевого аргумента
Какие факторы диктуют выдачу исключения, если аргумент является нулевым (например, если (является пустым), бросают новый ArgumentNullException ()), в противоположность проверке аргумента, если это является пустым заранее.
Я не вижу, почему исключение должно быть выдано вместо того, чтобы проверить на пустой указатель во-первых? Какое преимущество находится там в подходе исключения броска?
Это для C#/.NET
Спасибо
5 ответов
Ваш метод может делать одно из трех, когда аргумент равен нулю. Он может вызвать исключение, он может вернуться, ничего не делая, или он может сделать предположения и попытаться продолжить. Я предполагаю, что вы пытаетесь выбрать между первыми двумя вариантами.
Поскольку вызывающий метод всегда может проверить аргументы перед вызовом вашего метода, он может предотвратить передачу недопустимых значений. Это верно независимо от того, как ваш метод обрабатывает недопустимые значения.
Когда ваш метод вызывается с недопустимыми аргументами, он должен уведомить вызывающего абонента о том, что обработка не продолжена. Вы можете уведомить об этом, вызвав исключение или вернув значение ошибки. Если вы проверите значение null и не вернете значение ошибки, вызывающий метод будет считать, что ваш метод обработан без ошибок.
Как вы хотите, чтобы вызывающий метод обрабатывал случай, когда ваш метод не обрабатывается? Если передача null является нормальным явлением и должна быть легко обработана вызывающим методом, возвращающим ошибку для нулевого аргумента, это приемлемо.В этом случае вызывающий метод либо проверяет аргументы до, либо возвращаемое значение после того, как выбор остается за тем, кто пишет вызывающий метод.
Если пустое значение передается очень редко, создается исключение. Вызывающий метод может предотвратить исключение, проверив аргументы перед вызовом вашего метода, как указано выше. Вызывая исключение, стек вызовов можно развернуть без добавления большого количества кода.
Резюме:
Если аргумент, установленный в null, является обычным, и вызывающий метод должен быть написан для обработки возврата вашей функции без каких-либо действий, просто верните значение ошибки. Если нулевой аргумент встречается редко и нельзя ожидать, что вызывающий метод обработает ваш метод, ничего не делая, генерирует исключение, поэтому стек вызовов разматывается.
Обычно вы генерируете исключение ArgumentNullException, когда передается аргумент, значение которого равно нулю, но "никогда" не должно быть нулевым. Это конкретное исключение ArgumentException для работы с нулями.
Часто, если вы знаете, что собираетесь получить нулевые значения в качестве аргументов, вы проверяете наличие null и соответствующим образом планируете остальную часть вашего метода - часто создавая записи, если их нет, или выполняете другую подпрограмму, чем это было бы ' ve запускается, если присутствует действительный аргумент. В этом случае я обычно не использую ArgumentNullException, потому что я планирую, что значение null будет допустимым вводом.
Я использую ArgumentNullException только тогда, когда я уверен, что что-то не должно быть нулевым, когда оно попадает туда, и я хочу отметить аргумент, который определен как «недопустимый».
Как автор метода, вы должны решить, можете ли вы разумно вывести , что вызывающий мог иметь в виду под null . Если можете, примите меры. Если вы не можете, бросьте ArgumentNullException , чтобы сообщить вызывающей стороне, что они дали вам значение, которое вы не можете использовать.
Это защитное программирование - умереть как можно раньше и как можно более информативно, вместо того, чтобы пытаться хромать вместе с частично действительным состоянием, которое превращается в гораздо более тонкие (и трудные для исправления) ошибки.
Речь идет о принятии решения о том, каков контракт для вашего метода. Если вы хотите, чтобы в контракте было указано, что вызывающие абоненты не должны передавать null , вы должны генерировать исключение, если вы его получите. Не верьте, что звонящий никогда не совершит такой ошибки! OTOH, если вы хотите, чтобы контракт не был настолько ограничительным в этом аргументе (что бы это ни значило; либо ничего не делать изящно, либо какое-то другое поведение), тогда исключение явно неверно.
Что бы вы ни делали, задокументируйте . Дайте бедному абоненту шанс сделать все правильно, прежде чем бросать вещи в ваш метод ...
Никогда не пишите код, который проверяет наличие нулевого аргумента, а затем ничего не делает. Скрывать ошибки в клиентском коде совершенно неправильно, вы хотите быть максимально полезными, когда ваш API не используется должным образом.
ArgumentNullException очень полезен.