Проверка на «ноль» - PullRequest
       16

Проверка на «ноль»

1 голос
/ 23 ноября 2011

Имеет ли C# эмпирическое правило или договор соглашения о кодировании, который обрабатывает возможный аргумент null?

В качестве примера я пишу собственный метод, который получает параметр byte[] data.

public static string ConvertDataToMyOwnAndCustomString(byte[] data) { ... }

Теперь - что мне делать, если переданный data равен null?

Должен ли я оставить все как есть, чтобы произошло возможное NullReferenceException?Или я должен написать чек и сделать что-то вроде этого:

if (data == null) return null;

Ответы [ 4 ]

8 голосов
/ 23 ноября 2011

Общепринятым шаблоном является выдача ArgumentNullException

if(data == null) { throw new ArgumentNullException("data"); }

, если клиенты действительно ошибочно передают null в ваш метод.В наши дни вы можете даже выполнить это требование с помощью Кодового контракта:

Contract.Requires(data != null);

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

2 голосов
/ 23 ноября 2011

Я думаю, что наиболее распространенная модель:

if(data == null) 
    throw new ArgumentNullException("data");
1 голос
/ 23 ноября 2011

Ответы Джейсона и Кристофера верны. Я просто хочу добавить к ним;

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

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

1 голос
/ 23 ноября 2011

Это действительно все зависит. Где этот метод живет? Как часто он будет использоваться повторно? Это только для этого приложения, или это часть библиотеки кода, которая будет использоваться снова?

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

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

...