public const string NullTaxId = "TaxID does not exist";

серьёзно? И потом такой мусор напечатать на каком-нибудь счете?

Когда-то это был форум программистов (с)

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

Постепенно этот холивар переходит в соседний: null vs. 0 vs. "" vs. "Тут ничего нет"

Предполагаю, что если прога вылетает, то это именно то что хочет увидеть пользователь

а кто сказал, что прога будет вылетать?

Если ты не проверяешь полученное значение или не оборачиваешь вызов в try-catch, то сам дурак.

серьёзно?

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

И почему лучше в каких-то местах проверять на null и не проверять на NullTaxId?

Дело то ведь не в одном конкретном случае, а в "глобальной" проблеме.

этот холивар

ну так с самого начала об этом и говорилось, а то уж сколько времени никаких сообщений вообще не было.

Хоть можно узнать различные точки зрения, тоже иногда полезно

Если ты не проверяешь полученное значение

Ну так собственно в этот то и есть проблема.

Проверять х раз на null где только пользуем или на nullObject только там где действительно надо.

А ведь присваивание может происходить в одном месте, а использование в другом и ищи потом откуда там null.

не оборачиваешь вызов в try-catch

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

И всё сразу ясно, в этом месте проблема возникла. А не ждать когда указатель понадобится, а потом сказать - "получили нулевой указатель".

И почему лучше в каких-то местах проверять на null и не проверять на NullTaxId?

Сколько видел кода - любое введение своих собственных обозначений для "налл", "нуль" и прочего заставляет проверять кроме стандартных обозначений ещё и свои собственные. Т.е. просто прибавляется работы.

Т.е. вместо привычных условных

if (null)

else if (0)

становится

if (null)

else if (0)

else if (empty)

else if (whateverAdditionalDesignation1)

else if (whateverAdditionalDesignation2)

...

Причём все варианты, кроме двух первых, обычно сводятся к двум первым. Т.е. все последующие проверки, кроме двух первых, избыточны.

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

Варианты есть? При каких случаях что лучше использовать?

Так с ходу сложно придумать нормальный пример.

Попробую сформулировать так: если null не является ошибкой, то можно подумать над возвратом null объекта.

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

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

Собственно говоря, объект с дефолтным состоянием по сути и является null объектом. И такой подход используется довольно часто - создаем объект, после чего "подправляем" пару (из 100500) полей и в бой :)

Вбиваешь фамилию, клацаешь "Дальше". Если клиентов с такой фамилией несколько, то появляется список с выбором. Если такой клиент один, то сразу открываются данные клиента.

Зачем так делать? Это лишь запутывает пользователя, нисколько не ускоряет работу. Из-за разного поведения в том или ином случае и невозможности предсказать, какой именно случай будет. Чем более одинаковая работа по всем кейсам, тем больше автоматизма у пользователя вырабатывается. Когда ему может вывалиться то список, то заполненная форма, то пустая форма - ничего не вырабатывается.

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

Зачем так делать?

Это просто пример, когда подход с null объектом становится более оправданным.

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

Все зависит от конкретного юз-кейса.

Может быть реализовано несколько вывовод поиска.

Например, если было введено 3 или меньше знаков, то пользователь может нажать "Enter" и перейдет к списку.

Если больше 3 знаков то начинает работать всплывающее меню/автозаполнение. При этом если во всплывающем списке больше одного айтема, то по "Enter" будет переход к списку. Если в списке ровно 1 айтем, то редактирование этого айтема. Если же список пуст, то по "Enter" переходим к созданию нового клиента.

Такой подход вполне может сократить количество кликов. Ну и далеко не все и не всегда работают с мышью ;)

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

Вот ведь негодяй, сам запретил тут писать о программировании квантовых программ, сам всех разогнал!

А теперь приходит и говорит - а давайте устроим холивары "виндавс против линукса, интел против амд" итдт итп....

*****

По теме нулей, когда блокчейн возвращет нули - это грустно! печально! гораздо веселей когда возвращает числа!

сравните картинки:

это уже бабосиками, так гораздо веселей:

А теперь рассказывайте, как можно зациклить списки : https://foren.germany.ru/showmessage.pl?Number=40889039&Bo...

Fragen und Antworten - Программируем калькулятор пособий для беженцев вместе.

сам запретил тут писать

Сколько видел кода

интересно узнать абсолютные цифры

Функция возврата айди не знает контекста своего вызова

Судя по тому, что обо всём что в скобках вам глубоко плевать, мне сложно понять что имелось в виду

Зачем обычному мапу что то еще знать?

Вот по месту вызова и обрабатывайте этот налл - бросайте исключение

ну так об этом и идет речь, только похоже вы хотите бросать исключение после вызова функции, а смысл?

Зачем повторять одну и туже работу при каждом вызове функции?

в случае если фабрика по какой-то причине не может создать этот объект, нужно возвращать null

А почему null, а не сразу исключение, тогда сразу всё заткнется без каких то дальнейших шагов.

И чем раньше мы пробросим ошибку наверх, тем лучше.

именно так

далеко не все и не всегда работают с мышью ;)

Я работаю и мышью, и клавой. Мышью двигаешь в нужные места интерфейса, клавой жмёшь хоткеи. Когда привык к софту и знаешь хоткеи, работа идёт быстро.

А почему сразу должно быть исключение, если нулл является одним из ожидаемых значений?

А почему сразу должно быть исключение

Предположим обратное...

Получили, что значение объекта базы нулевое, что делаем дальше?

if(db == null) ...

Можно ли возвращать null из функции?

Вот ты ж, изобретатели велосипедов...

В шарпе можно. Но не нужно. В хаскеле / sml / tasm нельзя. Да даже в паскале нельзя. Я ответил на твой вопрос? :)

Лично я лично в яве, чтобы сигнализировать отсутствие значения, задекларирую что метод возвращает Optional. Это не хаскеловский Maybe, но тоже можно жить.

То, что предписано для не назначенного значения.

В шарпе можно. Но не нужно....Я ответил на твой вопрос?

Не совсем. просто как мнение.

Нужны правила отчего не нужно. Запрещаем вообще или есть какие то исключительные случаи?

Да даже в паскале нельзя.

В каком именно?

https://www.oreilly.com/library/view/delphi-in-a/156592659...