K
плюс дополнительно накинуть мапинг что отправлять на морду, а что лучше закинуть в логги и отправить на анализ
Size: a a a
2020 January 28
K
получается бред, на каждом контроллере мы должны накидывать те типы описанных эксепшинов, которые будем тут юзать, либо городить все сразу в BaseAppError и там мапать и пускать в нужную логику
RR
у нас логируется все, с разным типом - инфо, ошибка, ворнинг и тд
K
у нас логируется все, с разным типом - инфо, ошибка, ворнинг и тд
как вы групировали эксепшины по типу?
RR
получается бред, на каждом контроллере мы должны накидывать те типы описанных эксепшинов, которые будем тут юзать, либо городить все сразу в BaseAppError и там мапать и пускать в нужную логику
у вас отличается логика рендеринга ошибок? у нас она всегда одна
RR
как вы групировали эксепшины по типу?
в плане логирования или чего?
K
нейминг какой был, брали название модулей для названия классов в эксепшинах, как вы не запутались в таком большом кол-ве обработок?
K
у вас отличается логика рендеринга ошибок? у нас она всегда одна
одна, формат скинул выше
K
json: {
id: 'unauthorized',
message: exception.message
}, status: :unauthorized, layout: nil
простенький для морды
id: 'unauthorized',
message: exception.message
}, status: :unauthorized, layout: nil
простенький для морды
K
что не нужно отправлять, уходит в логирование и на архивацию
RR
нейминг в зависимости от бизнес логики, к примеру у тебя секция оплаты, значит ошибки находятся в немспейсе Payment, и к примеру тебе клиент прислал ошибочную сигнатуру, ты и рейзишь класс Payment::InvalidSignature. У эксепшенов есть свой уникальный код, по которому тянется сообщение из локализации
а рендеринг в контроллере через обычный презентер форматирует вывод
а рендеринг в контроллере через обычный презентер форматирует вывод
K
Payment::InvalidSignature - значит у нас эксепшины должны содержать структуру вложенности исходя из бизнес логики, выходит мы пишем эксепшины либо по готовым кейсам, либо собираем сразу с новым кодом, много у вас таких блоков, не вызывало ли путанницы?
K
у нас на вскидку 72 основных и в каждом где то по 10-20 вложенных, многовато писать))
RR
все эксепшены обычно наследуются от базового, крайне редко, вводится базовый для нескольких классов, экспешен состоит только из указания его кода, все остальное реализовано в базовом
классов таких много, они максимально простые, в коде путаницы нет, и у нас обязательное покрытие тестами
классов таких много, они максимально простые, в коде путаницы нет, и у нас обязательное покрытие тестами
RR
сейчас классов около 110
K
module V1
module Partnership
class UnauthorizedMerchantError < StandardError
def message
I18n.t('errors.types.unauthorized')
end
end
end
end
K
классы такие же, с одним методом?
RR
похожего плана
MS
Ребята, сейчас еще накину говна на вентилятор. Вот если эксепшны правильно юзать: для каждой ошибки свой класс, на каждом уровне прикреплять описание и стектрейс и перепаковывать ошибки нижнего уровня в контейнер верхнего, то у тебя ошибка как пузырек высплывает с самого дна обогащаясь состоянием программы, которое привело к ошибке.
Ты потом в системе сбора и фильтрации логов можешь понять состояние программы, которое привело к ошибке. Если не использовать эксепшны, то как достичь такого понимания внешних факторов, которые привели к ошибке?
Ты потом в системе сбора и фильтрации логов можешь понять состояние программы, которое привело к ошибке. Если не использовать эксепшны, то как достичь такого понимания внешних факторов, которые привели к ошибке?
K
похожего плана
и таких 110?