@hell0w0rd, взгляд неплохо бы аргументировать, а то у нас все эксперты в политике, футболе и медицине, кроме, соответственно, политиков, футболистов и врачей
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Оценка кода
- Автор темы scorpion-ds
- Дата начала
Вурдалак
Продвинутый новичок
Я не думаю, что такое есть из коробки, но вроде это несложно делается. Нужно повесить на событие GetResponseForExceptionEvent штуку, которая по типу исключения достанет метаинформацию из конфига об HTTP-статусе, возможном обработчике и т.д.
Вурдалак
Продвинутый новичок
Чем же это лучше? У тебя в каждом action'е будет такой код. А если ты попытаешься указывать конкретный тип исключения, то ты столкнешься с проблемами, которые я описал выше.
Есть такой принцип. Single Responsibility называется. Controller just controls the request processing flow. Обработка ошибок не его забота. Это забота, как ни странно, товарища по имени Error Handler. Не люблю все эти слова mvc hmvc... юзайте SRP и будет легко и приятно, имхо. И Laravel я люблю именно за то, что он легок для следования SRP.
Помоему, ты процедурно мыслишь немного. В самом простейшем случае у Exception есть message. В случаях посложнее можно ClientNotFoundException, etc. насоздавать. и там по соглашениям, ключи для локализированного вывода ошибок. Или если уж совсем не вмешивать в модель такую инфу, да - делай маппинг вроде - ClientNotFoundException -> client_not_found -> локализация сообщения и вывод. Это лишь только вариант. Возможностей много.
"Явное лучше, чем неявное." Уже было. Однако, развитие программирования всегда идет по пути роста уровней абстракции.
Вопрос не в том, лучше ли абстрагироваться или писать процедурно, а в том, как именно лучше абстрагироваться от throw new MyExceptionClass, если есть множество одинаковых случаев.
Подходов всегда два: соглашения (laravel, yii, reactjs, etc) и конфиги (symfony).
Принцип SRP является частным случаем Бритвы Оккама, и рассматривать его надо в контексте, не противоречащем основному правилу.
Надо делать так просто, как это возможно, но не проще. В твоем случае выводы не совсем корректны.
SRP не связан с hmvc, а твои выводы приведут лишь к монолитности и хрупкости. Когда будут нужны изменения в логике обработчика для частных случаев придется писать простыню if-else или уходить в стратегию.
Пример моей реальной задачи, которую я решал осенью. В проекте приняли новый стандарт, по которому часть url на сайте должны стать с / в конце, а часть - без. Соответственно, весь трафик по проиндексированным вразнобой url надо было редиректить к стандартным. Единый exception здесь был бы как корове седло.
Последнее редактирование:
Вурдалак
Продвинутый новичок
А ты это решал как-то на уровне контроллеров? Проще, например, добавить флаг к параметрам нужных route'ов: если есть флаг и без «/» на конце, то редирект.
"Хотя на самом деле решения равноправны и сравниваться должны практикой."
Ну давай сравним. Не на практике, конечно, а на глаз.Перепишу свой метод так, как описывается в мануалах по ларавель.
PHP:
public function postUpdate(\Request $request, $id)
{
$client = Client::find($id);
if(!$client) {
abort(404, 'Client not found');
}
$this->authorize('manage', $client);
// И то я не сомневаюсь, что наверняка
// прям тут стали бы проверять права вручную,
// без помощи ларавелевского authorize, где
// правила авторизации описаны отдельно в своем провайдере или Policies
$validator = \Validator::make($request->all(), [
'title' => 'required|unique:posts|max:255',
'body' => 'required',
// много много строк...
// и конечно среди них будут правила валидации типа not_exists и unique
// которые сами залезут в базу и посмотрят все что надо
]);
if ($validator->fails()) {
return redirect()//->action or route...
->withErrors($validator)
->withInput();
}
$client->fill($request->all());
return redirect()->...;
}P.S. Да, я знаю что я тот еще догматик. Разносить по классам как в моем примере довольно дорого по времени. Но, мне кажется, даст большой выигрыш в дальнейшей поддержке.
Последнее редактирование:
Вот это вообще контроллеров не касается
Как Вурдалак уже заметил это проблема роутинга.
Я это решал на разных уровнях, где можно было - в nginx, а часть в логике приложения.
Например, были url вида zzz.domain.tld/title/, и оказалось, что при смене title внезапно теряется трафик на проиндексированные url.
Нужно все перевести на domain.tld/zzz/title.123.html, где 123 - id сущности.
Чтобы получить 123 надо сходить в базу, это уже логика приложения.
Так вот перед тем как выкинуть 404 контроллер должен определить что это старый формат, проверить zzz и по title узнать 123. Причем, для некорректного zzz надо выдавать одну ошибку, для несуществующего title - другую. Делать 2 редиректа сначала для zzz, потом для 123 нельзя - гугл против.
И тут со стройной логикой получается хрень.
у меня была куча ситуаций, когда legacy-код написан с уверенностью, что юзеры ходят стройными рядами и читают мысли дизайнера, а они оказались толпой идиотов, и внезапно надо переделать обработку неожиданной херни в половине из десятков частных случаев
Например, были url вида zzz.domain.tld/title/, и оказалось, что при смене title внезапно теряется трафик на проиндексированные url.
Нужно все перевести на domain.tld/zzz/title.123.html, где 123 - id сущности.
Чтобы получить 123 надо сходить в базу, это уже логика приложения.
Так вот перед тем как выкинуть 404 контроллер должен определить что это старый формат, проверить zzz и по title узнать 123. Причем, для некорректного zzz надо выдавать одну ошибку, для несуществующего title - другую. Делать 2 редиректа сначала для zzz, потом для 123 нельзя - гугл против.
И тут со стройной логикой получается хрень.
у меня была куча ситуаций, когда legacy-код написан с уверенностью, что юзеры ходят стройными рядами и читают мысли дизайнера, а они оказались толпой идиотов, и внезапно надо переделать обработку неожиданной херни в половине из десятков частных случаев
Последнее редактирование:
То, что я не согласен с твоим решением, не значит, что я предпочитаю try-catch как у @hell0w0rd.
Ты не на ту тему споришь со мной. Я о другом.
Твой подход красивый на бумаге, да забыли про овраги - когда придется менять поведение для части случаев, проброс исключений из модели напрямую в error handler не позволит обработать контекст, который находится в ведении контроллера.
Последнее редактирование:
Последнее редактирование:
Вурдалак
Продвинутый новичок
Твой кейс не противоречит его подходу, просто нужно было бы написать
PHP:
public function actionGetArticle($id, $title) {
$articleDto = $this->articleQueryService->get($id);
if ($articleDto->getTitle() !== $title) {
return redirect()->route('_article', ['id' => $id, 'title' => $articleDto->getTitle()]);
}
// ...
}
Последнее редактирование:
