AS
О каком декораторе и о каком событии идет речь?
я давал выше пример
Size: a a a
2020 March 26
AS
мидлварь ничего не знает о том, кто её вызвал
AS
она знает только, кого вызвать следующим
AS
и в этом она ничем не отличается от самого обыкновенного декоратора )
DS
я давал выше пример
Ссылку
DS
и в этом она ничем не отличается от самого обыкновенного декоратора )
Ну да и что? Это и есть вложенные декораторы. Но любая мидлтварь может завернуть петлю на любом уровне вложенности
DS
На входе стека мидлтварей всегда риквест, на выходе риспонс. Исключения бросаются в исключительных ситуациях и всегда всплывают в ErrorCatcher, который в демке и есть корневой мидлтварью.
AS
Смотри выше пример с RetryableException
AS
У тебя может быть такая цепочка мидлварей, например
AS
Request -> RetryableExceptionCatcher -> SomeLogger1 -> SomeLogger2
DS
Смотри выше пример с RetryableException
Зачем возвращаться в предыдущую мидлтварь, если авторизация в текущей, соответственно попытки все должны быть в ней же.
AS
Любой логгер может залипнуть, его можно заретраить, и совсем не обязательно при этом показывать ошибку
AS
Зачем возвращаться в предыдущую мидлтварь, если авторизация в текущей, соответственно попытки все должны быть в ней же.
Эээ, ну затем, что не потерять запрос
DS
Любой логгер может залипнуть, его можно заретраить, и совсем не обязательно при этом показывать ошибку
И ты первым логером два раза залогируешь?
AS
И ты первым логером два раза залогируешь?
Это решаемый вопрос же
DS
Это решаемый вопрос же
Это костыль, а не решаемый вопрос. Если проблема в мидлтвари во втором логере, то там он и должен делать повторные попытки.
AS
Окей, другой пример
AS
CustomRestResponseFormatter -> Authorizer1 -> Authorizer2
AS
Как прокинешь ошибку авторизации из второго авторизатора?
AS
И отформатируешь, и покажешь так, как это описано в спеке