IL
типа токен заекспайрился, или токен отсутствует вообще, или подпись токена не верна
Size: a a a
2020 March 06
IL
короче мне важно выбросить конкретную причину почему я юзера швыряю в 401 или 403
AM
а вообще нормальная ли практика из guard бросать исключение вместо простого return false?
не нормально
IL
потому я юзал и интерцептор
IL
у меня идея.. проверить токен, декодировать его.
и засунуть в req._payload данные
А потом уже в контроллере я достаю @AuthPayload() payload: IAuthPayload
и засунуть в req._payload данные
А потом уже в контроллере я достаю @AuthPayload() payload: IAuthPayload
IL
и работаю
AM
а хотя
“
Note that behind the scenes, when a guard returns false, the framework throws a ForbiddenException. If you want to return a different error response, you should throw your own specific exception. For example:
throw new UnauthorizedException();
”
“
Note that behind the scenes, when a guard returns false, the framework throws a ForbiddenException. If you want to return a different error response, you should throw your own specific exception. For example:
throw new UnauthorizedException();
”
IL
а.. блин.. ты уже тоже бросил
IL
потому что без этого гард не имел бы вообще никакого смысла и я бы описывал свой поведенческий декоратор
AM
мерзко конечно, ну ладно
IL
ну да, не сильно красиво получается.
Лучше бы они просто сделали правила что на возврат требовали бы какой-то undefined | HttpResponseSomething.. со статус кодом и ошибкой
Лучше бы они просто сделали правила что на возврат требовали бы какой-то undefined | HttpResponseSomething.. со статус кодом и ошибкой
IL
хотя так тоже не очень красиво, потому что причина отказа может быть разной и ее надо уточнять
A
мерзко конечно, ну ладно
Не вижу в этом проблемы. Как на меня, то Guard для того и создан, чтобы защитить ресурс или что еще и бросать конкретный эксепшн.
AM
Не вижу в этом проблемы. Как на меня, то Guard для того и создан, чтобы защитить ресурс или что еще и бросать конкретный эксепшн.
выбрасывать эксепшены на корректном поведении — так себе идея
IL
выбрасывать эксепшены на корректном поведении — так себе идея
в смысле бросать эксцепшн на корректном поведении?
Исключения же сделаны для того чтобы прервать контекст выполнения и сказать что дальше выполнение невозможно, потому что… блабла.
Исключения же сделаны для того чтобы прервать контекст выполнения и сказать что дальше выполнение невозможно, потому что… блабла.
A
выбрасывать эксепшены на корректном поведении — так себе идея
Я не про корректное поведение, а бросать эксепшн именно когда не true. Если корректное поведение, то согласен - это не есть гуд.
AM
эксепшены сделаны для исключительных ситуаций. Если мы ситуацию можем обработать и не успасть — она не является исключительной. Иначе эксепшен превращается в goto-программирование
IL
и так по паттерну, вся цепочка прерывается в том числе и вызывающий код который не проверяет “что конкретно вернулось”, а просто прерывается так же и бросает событие то той иерархии вызова которая отвечает за управление контекстном исполнения - то есть до экспресса/файстифая
AM
Мы считаем, что исключения должны редко использоваться как часть потока исполнения программы: исключения должны быть зарезервированы для непредвиденных событий. Предположите, что непойманное исключение прервёт программу и спросите себя: “Будет ли этот код работать, если я уберу все обработчики исключений?”. Если ответ “нет”, то, вероятно, исключения используется не в исключительных ситуациях.