Ну мое понимает null-объектка - это некий объект... "по умолчанию"

кхм-кхм...

у Match все геттеры, так что ты даже не сможешь изменить состояние объекта.

Рефлексией я что хочу, то и делаю. Причём могу даже удобных обёрток понаделать над каждым "лишь геттером", где через рефлексию обнажать его backing field, грязно надустанавливаться над его приватными сеттерами и совершать прочие непотребства. Все эти "приватности" - лишь рекомендация программисту, пользователю данного класса, что-то делать или не делать, чтобы помочь совершать меньше ошибок. Но запретить ему никто не может.

Рефлексией я что хочу, то и делаю. Причём могу даже удобных обёрток понаделать над каждым "лишь геттером", где через рефлексию обнажать его backing field, грязно надустанавливаться над его приватными сеттерами и совершать прочие непотребства.

В том, что ты можешь совершать непотребства мы все тут уже не один раз видели :)

Сути дела это все не меняет.

Если совпадения нет, то все равно возвращается валидный объект, а не null, т.е. фактически null-объект.

Можно конечно и с этой стороны посмотреть, но мне по душе больше классика

https://sourcemaking.com/design_patterns/null_object

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

ну камон, для каких-нибудь обработчиков я допускаю такое решение.

А представь - ты наговнякал таких структур для банального класса Address.

Передаёшь такой адрес в сервис отправки писем, сервис ессно очень умный, понимает, что адреса нет и ничего не делает.

Через какое-то время люди удивляются, почему клиент не реагирует на письма.

А представь - ты наговнякал таких структур

Представить можно много еще чего. Но всегда удобно иметь некие ориентиры.

По крайней мере, желательно разделить варианты когда возвращается простой (строка) или сложный объект.

И вот еще достаточно удобный вариант как враппер - всегда возвращается не нулевой объект.

Передаёшь такой адрес в сервис отправки писем,

А если нулл передаем, где будет отличие? "сервис ессно очень умный, понимает, что адреса нет и ничего не делает."

мой бы исключение как кидал.

исключение кидал

вроде как с правилом определились - исключения только в случае баальшой ошибки.

люди удивляются, почему клиент не реагирует на письма.

-------

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

"Отправитель" в любом случае не будет разбираться с этой проблемой.

Вспомнил проблему именно с ехсептионом по нулл.

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

Предыдущий товарищ, чтобы все не падало, на нулле аккуратно ловил ехсептион вне цикла и продолжал обработку.

А вот что там было от нулла и до конца - просто отбрасывал.

При хорошей нагрузке нулл случался в разных местах выборки - получалась разная сумма.

мой бы исключение как кидал.

------

Ээээ... т.е. задача должна сниматься при наличии нулла там где он может быть?

вроде как с правилом определились - исключения только в случае баальшой ошибки.

Не надо смешивать теплое с мягким:

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

Ну чтобы было понятноее. Throw (exception) и return это два технических способа вывалиться их программы и вернуть какое-то значение в исходную:

• Можно использовать только return,
• а можно переписать все только на throw без возвратов вообще

Извне разницы не будет видно и это только вопрос удобства, предпочтений, best practices, религиозных и сексуальных предпочтений. Поэтому важно разделить эти два аспекта: логика программы и способ возврата (исключения vs. возврат).

Когда использовать исключения, а когда возврат и в чем разница? Это следующий холивар. Я бы сказал, что принципиальное отличие исключений в том, что они умеют вываливаться иерархически через многие уровни и делают это по умолчанию (если их не поймали). Возвраты таким не занимаются и вываливаются только на один уровень выше. Отсюда вывод: если хочешь чтобы твой результат мог быть виден на все уровни выше, то используй исключения (throw). Если твой резуьтат только для одного исходного метода, то используй возврат (return).

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

У меня тут проблем нет. Всё достаточно прозрачно - исключения не должны управлять нормальной логикой программы. Один фиг на сколько уровней.

Я не хочу получать возврат "Пользователь не найден" если нет соединения с сервером.

Не надо смешивать теплое с мягким:

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

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

Когда использовать исключения, а когда возврат и в чем разница?

Каждый дро...т как хочет. Придёте вы на проект, и вы там не главный. Либо начинать дро...ть как все, либо валить. ))

Каждый дро...т как хочет. Придёте вы на проект, и вы там не главный. Либо начинать дро...ть как все, либо валить. ))

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

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

Во, о том и речь. Можно вернуть значение через return, а можно через throw. Но принимающий по любому будет должен ветвить логику и принимать решение. На фига тогда два механизма?

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

я хз, в чем вы там определились.

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

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

Вот у тебя функция «повернуть руль на х градусов». Функция видит, что в буквальном смысле «пизда рулю», но вида не подаёт. Ты едешь в дерево, а криминалисты потом делают отчет: руль должен быть повернут, но не повернулся.

Все довольны.

Вопрос в другом: есть два (почти) равных механизма - возврат и исключения - какой когда использовать?

Бросить исключение это один из способов вернуть из метода какие-то данные. Некоторые так их и используют - т.е. воспринимают их не как исключительную ситуацию, а как нормальную работу программы, один из способов ветвить логику. Заводят кучу бизнес-исключений, и возвращают их через бросание. Для вызывающего кода разницы фактически нет - так и так приходится обрабатывать и возврат, и бросаемые вызываемым кодом исключения. Но если по логике программы исключительной ситуации не произошло, смысла возвращать данные через исключения нет - можно вернуть обычным способом. Просто раньше в том же Сишарпе не было способов удобно вернуть кучу разнотипных данных без создания своего аггрегационного типа или пачки out параметров. А теперь можно возвращать кортежи без костылей.

На фига тогда два механизма?

Механизм иключений позволяет ЛЮБОМУ коду вернуть некий набор типов ЕДИНООБРАЗНО - т.е. через механизм исключений. Свой аггрегационный типа возврата, кортежи, out параметры - это всё не такой привычный и распространённый способ, как обработка исключений. То, что нужно обрабатывать исключения, знают все, а то, что в том или этом фреймворке первый параметр возвращаемого кортежа - непосредственно возврат метода, а второй (или out параметр) - это данные по исключительной ситуации, знают лишь те, кто читает руководства к фреймворкам.

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

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

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

Вон Гугел или кто там предлагает в Тетрис сыграть, если "опаньки!" и что-то пошло не так. Чё, Тетрис или три в ряд намутить не можешь, если адреса нет? Прояви креатив, инициативу, убеди клиента, что адрес ему на самом деле-то и не нужен, и без адреса люди как-то живут.

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