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

Question

У меня есть несколько разработчиков, которые постоянно ставят, если проверяет NULL

Например:

Run(Order order)
{
  if (order == null) return;
}

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

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

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

какие-нибудь хорошие статьи или предложения, которые помогут мне разобраться в этом?

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

Даже если функция не возвращает и просто выдает 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>

Answer 4

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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

Answer 8

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

Answer 9

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

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

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

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