господа, вы откуда все?

ебаноепхп

рассылка наверн) имею ввиду название канала ))

Я в канале запостил ссылочку

ебаноепхп

такой себе источник трафика...

@ebanoePhp

похвалил свой чатик)

поунижал другой)

похвалил свой чатик)

Тот самый случай когда сам не похвалишь никто не похвалит?

Как лучше назвать исключение? CannotSendEmail или SendEmailFailure ? Вроде как в названии исключения должно описываться что произошло, поэтому я за второй вариант

я за первый - failure бывают разные

причин для cannot может быть тоже вагон) ... я за второй) ... throw CannotSendEmail чо-т не звучит

если конечно более конкретизировать failure нельзя

если конечно более конкретизировать failure нельзя

вот поэтому я за первый)

наследование ведь

просто есть метод легаси который возвращает false

мне нужно бросить 'rcgiy gj 'njve gjdjle

экспшн по этому поводу

Как по мне, can/cannot подходит для тестов, что бы девопс мог понять, где отвалилось из названия не заглядывая в код.

причин для cannot может быть тоже вагон) ... я за второй) ... throw CannotSendEmail чо-т не звучит

throw new EmailNotSent

Но лучше конкретизировать, конечно

Exception driven development?

throw new EmailNotSent

Еще такой был спор ка клучше писать EmailIsNotSent EmailWasNotSent

Я был за второй вариант т.к дейстиве в прошлом

а не я вообще предлогал EmailHasNotSent

Еще такой был спор ка клучше писать EmailIsNotSent EmailWasNotSent

Не тот случай, где надо включать граммарнаци

Чо-т слов больше, а смысла не добавляется)) ... Всегда старался избегать лишних глаголов

Чо-т слов больше, а смысла не добавляется)) ... Всегда старался избегать лишних глаголов

+

От того, по какой причине не отправился емейл, зависит дальнейшая обработка. Может это временный сбой сети, а может адрес невалидный, а может еще что-то. Поэтому исключение должно нести информацию о причине

не на этом уровне

это метод сброса пароля - пароль сбросить не получилось - причина = не удалось отправить емайл

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

тогда, прости, нахрена вообще это оформлено как исключение?

но у меня там херня возвращающая true/false

если ты ОЖИДАЕШЬ, что оно может не отправиться

какое же это исключение

если ты ОЖИДАЕШЬ, что оно может не отправиться

что значит ожидаю? если я создаю исключение, то я получается любую ситуацию ожидаю

$this->ensureSecretIsValid($user, $command->getSecret()); $newPassword = $this->userProvider::genSecret(); $this->changePassword($user, $newPassword); $this->sendPasswordToUserEmail($user, $newPassword, $context->getUserRequestContext());

вот кусок кода

sendPasswordToUserEmail в этом методе я пытаюсь отправить письмо и если ВДРУГ не получилось кидаю экспшн

и показываешь его юзеру?

я не люблю исключения, которые показываются юзеру.

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

что значит ожидаю? если я создаю исключение, то я получается любую ситуацию ожидаю

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

и все надо заворачивать в try/catch

я порой сильно одобряю решение разработчиков го "хэндлить ошибки явно"

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

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

короч не все ошибки это исключения. Дальше ты лишь накладываешь на это ограничения твоего языка

короч не все ошибки это исключения. Дальше ты лишь накладываешь на это ограничения твоего языка

Вот я именно это имел в виду.

и показываешь его юзеру?

Ничего я не показываю. Это обработчик команды, и если он завершился исключением то шина его выбросит а я перехвачу в контроллере

почта ДОЛЖНА отправляться а тут херакс и не отправились

Если это не исключение то я не знаю что тогда можно считать исключительной ситуацией

Ничего я не показываю. Это обработчик команды, и если он завершился исключением то шина его выбросит а я перехвачу в контроллере

шина ничего не возвращает

она же шина

ни return ни throw

и все надо заворачивать в try/catch

Оно и завернуто. Только на уровень выше, т.к мне для выполнения программы нужно три функции выполнить последовательно. Если какая то не может выполняться то крошится с исключением. А дальше я уже в контроллере разбираюсь в чем дело если что то вдруг пошло не так. И по типу исключения я могу понять в чем беда

по сути своей шина команд нужна там где факт выполнения команды определяется уже после того как процесс где ты что-то в шину пихал отжил свое. Асинхронное взаимодействие. Тебе неизвестен результат операции просто. А если надо что-то отобразить - ивент на фэйл и pub/sub

ни return ни throw

Метод handle команды

Метод handle команды

"команда" это данные (ну или юзкейс), "handle" это хэндлер команды. По сути это просто сервис, процедура

"команда" это данные (ну или юзкейс), "handle" это хэндлер команды. По сути это просто сервис, процедура

Да

далее... процедура позрадумевает что она что-то может не сделать и в данной ситуации "мои полномочия все".

и вот в этой ситуации исключения оправданы.

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

и вот в этой ситуации исключения оправданы.

Ну так это мой кейс и есть

Есть процедура resetPassword

ну тогда юзай себе исключения че, удобно - юзай. не удобно (а такие ситуации происходят с ростом проекта) - не юзай)

Есть процедура resetPassword

Она или резетит пароль или выкидывает экспшн

я например юзаю event driven подходы часто и исключения просто так там плохо. Вместо этого я в твоем resetPassword лучше доменный ивент сохраню что "не получилось"

но для тебя это может быть не актуально) ты и так пользуешься исключениями как "неявный выход из функции что бы преобразовать результат операции в респонс о том что пользователь дурачек

это не хорошо и не плохо, просто факт

прими его и будь единым с ним

Я так могу любое использование классифицировать...правда пользователь тут не совсем уместен

Т.к не обязательно он запрос инициирует

именно поэтому подход сергея лучше

он возвращает результат который ты можешь отработать

и если в случае ошикби это исключительная ситуация ты можешь там и выкинуть исключение

но если это ожидаемо

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

Event sourcing подключать для сброса пароля?)

Кидай исключение если ты не знаешь в чём причина (почтовый сервер недоступен например, или по таймауту отавлился), в случае некорректного email или другой предсказуемой ситуации, используй сообщения. Исключения не инструмент для управления бизнес логикой. Они для прерывания. На то они и "исключения"