5916
Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез
Согласен, код ответа важен. Или если код ответа один, также хорошо иметь параметр в ответе, который может детализировать тип ошибки, если с одним кодом могут быть разные кейсы. Ну например 404, но могут быть не найдены разные сущности из запроса (может хреновый пример щас привел).
Читать полностью…
Вот пусть каждый и делает трансляцию ошибок
Имхо это зашквар пользователю показывать текст ошибки, которая пришла с бэка
Особенно эта сотня партнёров будет рада коду ошибки, который они смогут разобрать и что то сделать, а не опираться на какой то текст
1. Выбор языка на фронте это норма, если пользователь авторизован, то это просто перегружает настройку профиля. Если пользователь не авторизован и нет выбранного языка - это делается из браузера
2. Зачем бэку передавать язык, если он передаёт данные не привязанные к языку? Например не передаёт текст ошибки?
3. Это норма на каждом фронте делать ошибки, тем может даже отличаться в зависимости от того это веб или мобилка
Проблема в том, что бывают случаи, когда у тебя сначала один фронт. А потом приходит заказчик и говорит, а давайте прихерачим сюда еще 3 сайта, приложухи и заодно этот апи дадим 100 партнерам… и тут занавес, или все переделывать, или как-то жить и выживать. Я лучше сразу такие риски заложу, чем потом локти кусать, тем более, что на начальном этапе это проще простого.
Читать полностью…
Все так. Только еще есть неавторизованный пользователь, ну и вообще кейсы когда исходя из UI/UX надо делать выбор языка например в шапке сайта, а не в профиле. И кейс, когда по каким-то причинам в сервис не передали Accept-Language, и тогда надо определить дефолтную локаль, и желательно рассказать фронту, на каком языке ты ответил. И у меня дороже на фронтах делать перевод ошибок из кодов в текст, проще и я считаю лучше в одном месте на беке сделать.
Читать полностью…
И заголовок поправил наконец. ResponseBodyAdvice помог, я раньше на него натыкался в доке, но не допер, что им можно не только тело поменять.
Читать полностью…
Ну вы же поняли контекст? Виктор хочет локализовать текст при exception
Читать полностью…
Фильтры это реализация chain of responsibility
Т.е. в прямом направлении запрос проходит через логику до взрыва doNext(), в обратном проходит логику после возврата из doNext()
Все интерцепторы и обработчики ошибок это фильтр, который отвечает за реализацию mvc - он идёт последним в цепочке
Т.о. пишешь фильтр, после возврата из doNext() ставишь нужный хидер в респонс. Либо делаешь try-finally и в finally блоке ставишь хидер, тогда он будет установлен и при исключении
Да-да, это уже выше посоветовали - не успел попробовать прикрутить.
Читать полностью…
Ты понимаешь как оно работает от получения запроса до отдачи ответа?
Читать полностью…
2. В целом не за чем, но проще сделать что он всегда говорит в ответе, на каком языке он отвечает. Чтобы не придумывать как исключать запросы, где не надо это делать. Хотя в принципе можно, думаю.
3. То что ошибки надо иметь возможность обрабатывать как-то специфически на фронте - это факт. Бывают кейсы когда это необходимо. Но 90% сообщений можно кидать в Toast-message. Если конечно твой бек по уму сделан.
вчера подсвечивал уже, но у него там еще зоопарк мобильных)
Читать полностью…
Вообще обычно делают локаль пользователя, которая хранится у него в акк, её загружает с акк пользователя фронт и в этом языке отрисовывает
А ошибки - принято кидать кодами, а у фронта в каждой локали на каждый код свой текст
Ну так создай RestControllerAdvice и там обрабатывай глобально
Читать полностью…
Нет, не только при exception, но и там тоже, и не хочу, а уже сделал. Только надо еще заголовок поправить.
Читать полностью…
Я с php-симфони переезжаю. Ее сдирали со спринга судя по всему. Многое очень похоже. Я просто кайфую сейчас, многие вещи даже гуглить не надо, интуитивно делаю и работает. Только костылей меньше)
Читать полностью…
На самом деле подходы везде примерно одинаковые. Паттерн декоратор(враппер), который имплементится через явное делегирование внутри декоратора + оборачивание в свой специфический код иди через AOP.
В других языках могут быть другие подходы само собой, но сомнительно что отличтя кардинальные.
Вот сейчас с этим всем и разбираюсь. Прошу ногами не пинать сразу, я Java начал изучать на этой неделе:) Пошел читать как работают фильтры.
Читать полностью…
Не подходит, мне надо обрабатывать ошибки глобально, а не в каждом контроллере это писать.
Читать полностью…