как мне объяснить, что проверки if (xyz == null) не являются защитными

Если ваш класс не может принимать null аргумент, лучше всего сделать следующее:

if (arg == null)
    throw new ArgumentNullException();

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

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

Это действительно зависит от конкретной ситуации. Редко бывает целесообразно давать общие предложения вроде «не помещайте в код нулевые проверки», как вы, кажется, указываете. Контракт класса должен определять, что законно, а что нет. Но если в контракте четко указано, что передача null недопустима, то исключение действительно является подходящим ответом.

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

Даже если функция не возвращается и просто выдает NullReferenceException, легче решить ошибку, если вы знаете, что аргумент был нулевым. Если функция выдает NullReferenceException, вы не знаете, что было null или чья это была ошибка.

Хочу добавить, что ArgumentNullException не зря принимает параметр.

Лучше написать

if(myArg == null) throw new ArgumentNullException("myArg");

чем бросать ArgumentNullException без paramName.

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

Если вы пишете много функций, это может привести к большим накладным расходам, особенно из-за отсутствия IntelliSense для строк. Я написал фрагмент кода для генерации этих проверок:

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
    <CodeSnippet Format="1.0.0">
        <Header>
            <Title>Check for null arguments</Title>
            <Shortcut>tna</Shortcut>
            <Description>Code snippet for throw new ArgumentNullException</Description>
            <Author>SLaks</Author>
            <SnippetTypes>
                <SnippetType>Expansion</SnippetType>
                <SnippetType>SurroundsWith</SnippetType>
            </SnippetTypes>
        </Header>
        <Snippet>
            <Declarations>
                <Literal>
                    <ID>Parameter</ID>
                    <ToolTip>Paremeter to check for null</ToolTip>
                    <Default>value</Default>
                </Literal>
            </Declarations>
            <Code Language="csharp"><![CDATA[if ($Parameter$ == null) throw new ArgumentNullException("$Parameter$");
        $end$]]>
            </Code>
        </Snippet>
    </CodeSnippet>
</CodeSnippets>

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

http://blogs.msdn.com/bclteam/archive/2008/11/11/introduction-to-code-contracts-melitta-andersen.aspx

Я не смотрел его, но на eiffel.com есть 2 презентации (слайды + аудио ) по теме дизайн по контракту. Эти ребята изобрели концепцию, так что если кто-то может объяснить это, так это они :-)

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

Если в контракте метода указано, что его аргументы не должны быть нулевыми, то правильным решением будет сделать его явным, используя Assert, например:

Debug.Assert( item != null, "Null items are not supported );

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

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

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

Все ошибки оказываются или кажутся глупыми, когда они обнаруживаются. Но вот такие проверки заставляют их разоблачать себя. А пока ошибок не видно. А для достаточно больших и сложных проектов вы не знаете, кто найдет ошибку и при каких условиях она будет обнаружена. Код, разработанный для обеспечения устойчивости, обычно имеет такие проверки повсюду, а также проверяет возвращаемые значения для каждой функции, которая должна включать значения ошибок. Таким образом, вы в конечном итоге кодируете семантику «Я не могу этого сделать, потому что подфункции, на которые я полагаюсь, не работают», которая на самом деле обрабатывается правильно. Большая ценность этого заключается в том, что вы можете довольно легко реализовать обходные пути или инструменты отладки с самооценкой. Почему вы хотите делать такие вещи, потому что самые сложные ошибки обычно зависят от обоих этих свойств для правильной отладки.

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

Вкратце: ни один код не может стать надежным, если предположить надежность окружающей среды.