AnrDaemon
Продвинутый новичок
Домен отправил и забыл… да-да.
Может, стоит уже проснуться?
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Exceptions
- Автор темы Adelf
- Дата начала
Может, стоит уже проснуться?
Возвращать статус
статус ответа команды
на наличие положительного ответа
к вызову команды
нет, создание этого ответа, для начала
в этом
правильно, потому как ты умалчиваешь условие когда ты возвращаешь http 400
но по твоим рассуждениям это выгдядит так
Код:
$result = $orderService->cancel(...);
if($result->status !== 'cancelled'){
http_response_code(400);
}не брызгай слюной, плиз
мне даже больше интересно, почему у него 403 возвращается в одном из моментов. У него домен знает про http коды? или такая продвинутая авторизация... что вообще все тогда можно 403 ошибкой возвращать. а не 400. По моему 403 когда пытаются сделать что-то сделать с отмененным заказом... вроде и правильно, но это пример когда авторизация сильно пролезла в домен. не самый лучший вариант.
он о REST вероятно, ресурс: order-123 запрещен.. на самом деле не суть, разговор то больше про 4xx код
у нас чаще 403 появляется когда вызывают action на который нет прав.
Да. Теоретически можно себе представить, что заказ стал недоступен этому юзеру, хотя только что был доступен. Но чтобы понять это, надо залезть в домен и иметь такое понятие как отмененный заказ. и что такие заказы становятся недоступными.
Ошибка, что заказ в принципе не может быть запущен заново, если отменен, вне зависимости от всяких авторизаций выглядит гораздо более логично. Поэтому я и не понял 403 ошибку.
Ошибка, что заказ в принципе не может быть запущен заново, если отменен, вне зависимости от всяких авторизаций выглядит гораздо более логично. Поэтому я и не понял 403 ошибку.
вопрос интерпретации что такое ресурс, заказ (с точки зрения rest) или сама команда cancel
но это можно и на уровне exception сделать
PHP:
class NotAllowedException extends DomainException{}
$order = $repo->get(123);
$order->calncel(...); // throw new NotAllowedException
$repo->store($order);
catch(NotAllowedException $e){
http_response_code(403);
}
ребята, прочитайте расшифровку аббревиатуры REST, пожалуйста - я пересказывать не хочу, а у вас юношеские фантазии пошли уже ... залезть в домен 
403 я написал просто для примера - можно 405 Method Not Allowed
нет указания, что 403 применяется ко всему объекту целиком - можно и для набора параметров
403 я написал просто для примера - можно 405 Method Not Allowed
нет указания, что 403 применяется ко всему объекту целиком - можно и для набора параметров
Последнее редактирование:
@grigori,
а это разве не про GET/POST/PUT/DELETE?
может назовешь это условие, дабы наши "юношеские фантазии" поприубавить
когда заказ отменен - дальнейшая смена его статуса может быть запрещена, так что 405 здесь может быть уместен
не существует научных теоретических условий возврата 400го кода. коды указываются в API
нет логической связи между тем, что я не приводил код, и условием 400го ответа. я не приводил код - это факт. твоя аппеляция к коду неуместна и бессмысленна. Л - Логика
Последнее редактирование:
AnrDaemon
Продвинутый новичок
HTML в принципе задуман, как расширяемый протокол.
Причём как внешне (добавлением новых возможностей), так и внутренне (расширением значения уже существующих, в разумных пределах).
Так что, например, в контексте REST, код 405 может относиться не только к собственно методу, но и к его применению в контексте определённых параметров. Не вижу объективного противоречия.
Кокретную причину отказа всегда можно описать в… ах, да, конечно HTTP/2…
Вурдалак
Продвинутый новичок
Я не вижу связи с https://en.wikipedia.org/wiki/Information_hiding.
IH — это, грубо говоря, то, что мы обычно называем инкапсуляцией в том смысле, что мы скрываем детали реализации. Но капсула может быть прозрачной, поэтому вот любят разделять эти понятия.
А как мы это должны обрабатывать? Если там есть бизнес-процесс (сага), который по событию «Не удалось оплатить отменённый заказ» сделает компенсацию, то тогда я бы сделал ошибку в виде события.
Тут может быть 2 варианта:
1. Состояние в момент отрисовки UI, тогда можно допускать RC.
2. После выполнения действия можно из command bus (да-да) или service возвращать список ошибок/событий, которые возникли. Среди них там может быть и то самое событие «Не удалось оплатить отменённый заказ».
И рисуй что хочешь.
На самом деле, лучше не через exception'ы. Я имею в виду, я в своё время наелся говна с таким кейсом, когда исключение на одном уровне вполне себе BusinessException и можно рассматривать как 400, а потом контроллер чуть-чуть поменялся, часть данных стала заполняться автоматически — и тут уж никак не скажешь, что это 400, клиент вообще не виноват. А варианты тут всякие:
PHP:
$this
->commandBus
->execute(new PayOrder($orderId, ...))
->errors()
->map([
function (CancelledOrderCannotBePaid $error) {
throw new BadRequestException(....);
},
function (OrderWasNotFound $error) {
throw new NotFoundResource(....);
}
]);
// vs
$orderErrors =
$this
->commandBus
->execute(new PayOrder($orderId, ...))
->errors()
->reduce([
function (OrderErrors $errors, CancelledOrderCannotBePaid $error) {
return $errors->withCancelled(true);
},
function (OrderErrors $errors, OrderWasNotFound $error) {
return OrderErrors::notFound();
}
], OrderErrors::none());
return new Response($this->render($orderErrors));
Последнее редактирование:
Отношение к Exception-ам определяется наличием опыта съедания говна с ними, как и с middleware.
Я как-то дорабатывал код с exception-ами, когда изменения каталога планировались раз в месяц, а по факту они ВНЕЗАПНО происходят ежедневно, и ежедневное перекачивание каталога на десятки мегабайт тысячами пользователей одновременно кладет сервера и внешний канал ДЦ. Добавить чуть больше логгирования с метриками в такой код проблематично - после отлова исключения остается только контекст самого исключения.
Я как-то дорабатывал код с exception-ами, когда изменения каталога планировались раз в месяц, а по факту они ВНЕЗАПНО происходят ежедневно, и ежедневное перекачивание каталога на десятки мегабайт тысячами пользователей одновременно кладет сервера и внешний канал ДЦ. Добавить чуть больше логгирования с метриками в такой код проблематично - после отлова исключения остается только контекст самого исключения.
Ну тут у тебя контроллер что-то уж больно умный. Сам какие-то данные достает и подставляет в запрос к service layer. Хотя если это все из HTTP-контекста не выходит(т.е. данные сохранились где-то в куках для примеру), то вроде и нормально...
В любом случае, я не вижу большой разницы в эксепшене с тем же $errors и структуре OrderErrors.
И еще, я могу понять когда простейшая валидация отвалилась, там да, некоторым удобно несколько ошибок, к каждому ошибочному полю, чтобы красиво в UI нарисовать красным, но вроде это уже давно не модно, серверно валидировать такие простейшие вещи да и если валидировать, то можно отдельным ValidationException с нужной структурой.
А все остальные случаи... там всегда лишь одна причина для отказа. Order not found - дальше продолжать смысла нет. Order status не тот - тоже смысла нет продолжать. У тебя бывали кейсы когда действительно несколько причин для отказа? Ведь в коде для этого надо все это предусматривать... формируя потихоньку error-ответ.
P.S. уже в который раз замечаю в твоих примерах функциональный подход с парсингом мета-инфы о параметрах функции. Выглядит красиво. Но перевернуть свое мышление и начать применять у себя... что-то как-то не представляю. Надо попробовать
видимо, работу с рефлексией у вас там делает какая-то отдельная внутренняя мини-либа...AnrDaemon
Продвинутый новичок
Клиентская валидация не является заменой серверной валидации.
ну давай уж такие истины не будем обсуждать. я говорю лишь об удобном выводе ошибок для каждого поля.
Можно вообще не проверять, но при попытке создать VO Email::create($request['email']); вылезет эксепшен. и его вполне можно отдать в качестве errorMessage. Беда только в том, что оно на первом же поле спотыкнется и не оповестит об ошибках в других полях. Но если мы подразумеваем нормальное UI, то такой ошибки вообще не должно произойти, так что пофиг.
Вурдалак
Продвинутый новичок
Я не понял.
Ты имеешь в виду накопить $errors и выкинуть OrdersErrorsException? Ну, технически может разницы и нет. Но семантически смешивать бизнес и технические ошибки иногда становится неудобно. Здесь есть еще одна не самая очевидная проблема: если у тебя несколько вложенных bounded contexts, а пользователь «отвечает» только за самый верхний, то при вылете FooBusinessException откуда-то из глубин мы можем ошибочно решить, что нужно отдавать 400, хотя клиент может быть вовсе не виноват: то есть, одно и то же исключение может быть на уровне API отображено по-разному в зависимости от контекста.
Более того, исключения — это такая сложная штука, когда в одном контексте исключение у нас checked, а в другом оно уже должно рассматриваться как unchecked, поскольку может быть полностью иррелевантно текущему, то есть по-хорошему его нужно оборачивать в другое исключение, если мы хотим такого же поведения, как в Java.
Ну, как тебе сказать. Иногда просто ошибки и события переплетаются. Например, человек вводит неверно код из SMS в N-й раз: с одной стороны, мы должны сообщить об ошибке (CodeWasWrong) (показать капчу, может быть), с другой — инвалидировать сущность (FooRequestWasInvalidated). Если тупо выкинем exception, то до инвалидации не дойдет и будет проблема с безопасностью.
Или, например, человек лайкает девушку в Tinder: он может увидеть как ошибку «Купите Tinder Plus», но одновременно с этим — «Вы сматчились» (но написать не сможете, пока-таки не оплатите Tinder Plus — этот бред я выдумал на ходу, но как вариант).
Здесь еще есть такое преимущество: я могу выкидывать исключение, есть нет соответствующего замыкания с нужным событием/ошибкой: это позволит иметь гарантию того, что при добавлении нового события я добавлю обработку везде. В случае с исключениями можно где-то прое#ать try .. catch и получить проблему, например, ложным 400 Bad Request по FooBusinessException, как описывал в самом начале.P.S. уже в который раз замечаю в твоих примерах функциональный подход с парсингом мета-инфы о параметрах функции. Выглядит красиво. Но перевернуть свое мышление и начать применять у себя... что-то как-то не представляю. Надо попробовать
Мои пойнты примерно такие:
1. Делать прямой мэппинг FooBusinessException => http error code — это ошибочный подход.
2. Пускать бизнес-ошибки по отдельному полю errors/events в response команды/сервиса — более безопасный подход, и он позволяет достаточно явно семантически разграничивать бизнес ошибки и технические.
3. Несколько ошибок/событий — более гибкий механизм, чем исключения.
Вурдалак
Продвинутый новичок
Разница в том, что PhpStorm \LogicException и \RuntimeException по умолчанию считает unchecked-исключениями и не требует `@throws` или `try .. catch`
По поводу «Post already published» я че-то так и не услышал ответа. Но я так понял речь идёт об идемпотентности. А это важная штука. Не буду тыкать пальцем в один известный банк, но у него был (?) такой прикол в интерфейсе, что если ты делаешь перевод на счёт другому клиенту, у тебя лагает Интернет, то появляется окошко: «Что-то не получилось, кажись, попробуем снова?» и «попробуем снова» приводило к ещё одному переводу. А по-хорошему мы должны получить в ответ ровно то, что и в первый раз и перевод должен быть только один, естественно.
Если обобщить, то у нас есть некая команда и список событий, которые снова не возникнут (нельзя убить убитого человека), но хочется видеть в ответе. Для этого я имею опциональный command id (UUID), по которому я могу на несколько часов записать результаты выполнения команды и отдавать всегда одно и то же, даже не пытаясь выполнить команду реально. Command id обычно приходит с клиента, естественно, потому что только он может сказать новый это запрос или попытка повторить старый лаганувший.
Для всяких OrderWasNotFound можно просто флаг «not_found» какой-нибудь отдавать из command bus, отдельного исключения это тоже что-то не заслуживает.
Последнее редактирование:
Вурдалак
Продвинутый новичок
Представь, что в PHP появился скалярный тип string<1,..> («строка ненулевой длины»). Наверное, она будет выкидывать TypeError или типа того при пустой строке. Ты будешь ловить TypeError? Или не будешь использовать такой синтаксис? Мне кажется, что assertion'ы можно рассматривать как расширенные type hinting, если хочешь: не нужно это ловить, до этого просто не нужно доводить.
По-моему, у меня какое-то дежавю, раз в полгода обсуждаем, что assertion'ы и клиентская валидация — это разные вещи, но вот снова опять.