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

Скользкий котяра, скользкий

Есть конкретный пример, ожидается конкретный ответ.

Можно даже сказать - предписано выдать сообщение о конкретной ошибке и выйти из программы. (Пысы: в проге несколько соединений к базам данных)

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

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

if(db == null) ...

чел, ты не дурачок случаем?

Исключение надо кидать не в мной упомянутой функции, а выше.
Скажем, функция определяет, является ли клиент Местной фирмой или иностранной. Т.к. для этого налоговый номер необходим, то тут сам бог велел кинуть исключение.

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

Ну можно и сразу исключение. Зависит от фабрики и от того, что она должна возвразать.

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

Как бы там ни было, это уже детали реализации фабрики и договоренностей между архитекторами.

Я работаю и мышью, и клавой.

Всем плевать на то как ты работаешь :)

Программы пишутся для того, чтобы с ними было удобно работать конкретному клиенту. Уверяю тебя, никто не думают о том, как ты работаешь за компом ;)

не скользкий. а опытный...

у тебя есть два субтипа объектов:

- который может не назначаться значением

- обязан иметь значение.

для первого нулл является нормально возвращаемым значением

для второго нулл - ситуация возникающая при ошибке.

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

Вопрос об исключениях вообще элементарен

- либо исключения используются для обработки ошибочных ситуаций

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

Соответственно - либо - да, либо - нет.

чел, ты...

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

Разве с переходом на личности можно прийти к какому-либо результату?

Получили, что значение объекта базы нулевое… Т.к. для этого налоговый номер необходим

В упор не вижу никакой связи между этими двумя высказываниями.

Ну а если перейти к вашему примеру, то правильно ли я понял, что в одном случае нужно выдавать нулл, а в другом исключение? То есть намеренно делаем поведение функции непредсказуемым, для того кто не в теме.

клиент Местной фирмой или иностранной

почему фирмой? И откуда можно взять что именно определено как местная страна? Это всё видно отсюда? GetTaxIdByCustomerId(int)

не скользкий

еще как, пришлось за хвост дёрнуть, чтобы получить цивилизованный ответ

В принципе можно было и согласится, но смущает "статистика"

Постоянно попадается что-то типа этого, но ни разу не наоборот.

https://medium.com/javarevisited/just-dont-return-null-dcd...

https://medium.com/@jadhavsid1101/why-returning-null-from-...

по мне так все логично

Функция, возвращающая налоговый номер, выдаёт null, Если он не определён.

почему фирмой? И откуда можно взять что именно определено как местная страна? Это всё видно отсюда? GetTaxIdByCustomerId(int)

если налоговый номер начинается с DE, то фирма местная. Если с какого-то иного кода страны, то иностранная.

Если налогового номера нет, то это исключение.

по мне так все логично

Только потому, что вы вероятно "живете" в этом домене.

А по мне, функция берет на себя слишком много и для этого много нужно смотреть реализацию функции.

Если налогового номера нет, то исключение.

Если налоговый номер не определён, то возвращаем null

Если налоговый номер неправильный, то?

Если фирма иностранная, то исключение.

Если клиент не найден то ?

И по вашему описанию хотелось бы видеть, что то в виде этого

string? GetTaxIdByCustomerId(int customerId, string residentСountryId)

И какое отличие от "номера нет" от "номер не определен"?

А если клиент не фирма?

В принципе можно было и согласится, но смущает "статистика"Постоянно попадается что-то типа этого, но ни разу не наоборот.https://medium.com/javarevisited/just-dont-return-null-dcd...https://medium.com/@jadhavsid1101/why-returning-null-from-...

Фигня все это, от лукавого. Нет никаких причин не использовать null или любое другое (другие) значения, если они прописаны в доках функции. Более того, если есть только один единственный особый случай, то гораздо удобнее использовать null. Ну типа: "Край, ничем не могу помочь. Разбирайся сам."

В первой ссылке какие-то мантры. А по поводу аргументов из второй ссылке:

• Return an empty collection - Это не по теме. Мы говорим о значении, а не о коллекции. Автор съезжает с темы.
• Throw an exception. Это вообще другой холивар: return vs. exception. Опять автор съезжает да и проблему не решает, т.к. это надо ловить выше.
• Return an optional value. This way, the caller can use the optional value to check whether a value was returned or not, and handle the empty case appropriately. - Ну и в чем выгода? По любасу надо проверять возврат по поводу особого случая?
• Use the Null Object pattern. Здесь типа даже если ничего не возращено, то все идет по плану. Это вообще зашквар какой-то. Типа юзер не найден, но далее все идет по плану. Это как?
• Use assertions. И чем это отличается от явных проверок? Ну впрочем это лучшее решение, чтобы проверять отсутствие null во время выполнения если это нельзя проверить во время компиляции (как в Котлин например). Полезно, если null вообще невозможен. Но мы же говорим о случае, когда она возможен.

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

Если налогового номера нет, то исключение.

Если налоговый номер не определён, то возвращаем null

С точки зрения информации в БД это один и тот же случай .

А по мне, функция берет на себя слишком много

Когда пытается возвращать сочинения вместо наллового айди.

Вернуть налловый айди из базы это работа с базой. Интерпретировать возврать это бизнес-логика.

В первой ссылке какие-то мантры. А по поводу аргументов из второй ссылке

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

Более того, если есть только один единственный особый случай, то гораздо удобнее использовать null.

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

Мы говорим о значении

не знаю отчего вы так решили, разговор о том что может возвращать функция. Если требуется value type выделить, давайте выделим и разберем их отдельно

чем раньше такие nullpointerexception возникают

так именно об этом и разговор. Только если НПФ возникает - это уже ошибка, а раз ошибка то исключение должна выбрасывать функция.

С точки зрения информации в БД это один и тот же случай .

Тогда в каком случае выдаётся null, а в каком исключение?

Когда пытается возвращать сочинения вместо наллового айди.

Это всё конкретный пример, на основе которого нужно выработать определенные правила, а после их проверить на других примерах.

Тогда в каком случае выдаётся null, а в каком исключение?

см. выше.

см. выше. Goto давно запрещено

Если налогового номера нет, то исключение.

Если налоговый номер не определён, то возвращаем null

сказочный долбоёб

Понимаю, неделя выдалась плохая, настроение фиговое, хочется с кем-то поругаться. Бывает.

Самое простое обвинить кого-то, не задумываясь о первопричинах.

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

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

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

Паскаль он один. Виртовский. Ну, пусть будет борландовский турбо-паскаль, ладно. Называть дельфи паскалем как называть шарп - си.