нулевые объекты против пустых объектов - PullRequest
13 голосов
/ 27 октября 2009

[Это результат Рекомендация: Должны ли функции возвращать ноль или пустой объект? , но я пытаюсь быть очень общим. ]

Во многих унаследованных (производных) кодах C ++, которые я видел, существует тенденция писать много из NULL (или аналогичных) проверок проверить указатели. Многие из них добавляются ближе к концу цикла выпуска, когда добавление NULL -check обеспечивает быстрое исправление сбоя, вызванного разыменованием указателя - и не так много времени для исследования.

Чтобы бороться с этим, я начал писать код, который принимал (const) ссылочный параметр вместо (гораздо) более распространенной техники передачи указателя. Нет указателя, нет желания проверять NULL (игнорируя угловой случай фактического наличия нулевой ссылки).

В C # присутствует та же «проблема» C ++: желание проверить каждую неизвестную ссылку на null (ArgumentNullException) и быстро исправить NullReferenceException s, добавив проверку null.

Мне кажется, что один из способов предотвратить это - избегать пустых объектов, используя вместо этого пустые объекты (String.Empty, EventArgs.Empty). Другим было бы выбрасывать исключение, а не возвращать null.

Я только начинаю изучать F #, но кажется, что в этой среде гораздо меньше нулевых объектов. Так что, может быть, вам не нужно, чтобы вокруг было много null ссылок?

Я лаю не на том дереве?

Ответы [ 11 ]

0 голосов
/ 27 октября 2009

Вы не можете всегда возвращать пустой объект, потому что «пустой» не всегда определяется. Например, что означает пустое значение типа int, float или bool?

Возвращение указателя NULL не обязательно является плохой практикой, но я думаю, что лучше возвращать (const) ссылку (где, конечно, имеет смысл это делать).

А в последнее время я часто использую класс Fallible:

Fallible<std::string> theName = obj.getName();
if (theName)
{
    // ...
}

Существуют различные реализации, доступные для такого класса (проверьте Google Code Search), Я также создал свой .

...