Возвращает значение null из метода XNA API xbox360.Плохая практика? - PullRequest
Новая
       52

Возвращает значение null из метода XNA API xbox360.Плохая практика?

0 голосов
/ 24 июня 2011

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

Int GetFieldByID( String IDString );

так 

Int m_MyReturnedID = GetFieldByID( "myGamerTag" );

Теперь, я бы предположил, что если идентификатор не может быть найден, мы могли бы вернуть -1 и затем обработать это вместо возврата нулевого объекта, поскольку это может фактически означать, что что-то пошло не так внутри. Во всяком случае, я только что был на сайте разработчиков XNA и смотрел на это:

http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.net.networksession.findgamerbyid.aspx

Как видите:

Возвращаемое значение

Соответствие сетевых геймеров запрошенный идентификатор или ноль, если нет соответствующий игрок был найден.

Я ошибаюсь в своем предвзятом мнении, что возвращение нулевого объекта, подобного этому, является плохой практикой? У меня внезапно возникают сомнения, потому что я предполагаю, что разработчики M $ должны точно знать, что они делают для таких сервисов, как XNA / Live и т. Д., Особенно после различных итераций.

Спасибо

1 Ответ

1 голос
/ 24 июня 2011

Здесь вы описываете две разные ситуации:

  • Возвращает тип значения, который не может быть нулевым (как в вашем примере)
  • Возвращает ссылочный тип (как в API, который вы фактически связали) - и это относится также к Nullable типам.

A тип значения не может быть нулевым, поэтому вы можете вернуть -1 для ситуации "not found". Вы часто не можете вернуть 0, потому что большую часть времени ноль является допустимым значением. В этом случае -1 является часовым значением .

Теперь переменная , которая ссылается на ссылочный тип (class) объекта может быть нулевой (то есть: не ссылаться ни на какой объект). Однако вы также можете создать свой ссылочный тип так, чтобы он имел «состояние дозорного», что означает «недопустимый».

Это, конечно, полная боль в заднице. Не делай этого.

Вместо проверки этого: 

if(foo != null) ...

Вы будете делать это: 

if(foo != null && foo.IsValid) ...

Что является более трудоемким, и даже если что-то принуждает ненулевое значение, вам все равно придется сделать это: 

if(foo.IsValid) ...

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

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

...