Java Производительность обработки ошибок Spring в веб-приложениях

Question

Это сфокусировано на разработке веб-приложений на сервере. Я предпочитаю использовать в своем приложении коды состояния HTTP, которые отображаются в моей бизнес логи c. Например, если запрос сделан, а пользователь не найден, я сгенерирую исключение и обработаю его с помощью @ControllerAdvice или @ExceptionHandler и сопоставлю с 404, не найденным. Иногда они находятся внутри блоков try catch для регистрации и повторного выброса исключения. Я предпочитаю этот путь, потому что разработчик API может просто посмотреть на код состояния и двигаться дальше, не нужно десериализовать, если это ожидаемая ошибка клиента. Коллега считает, что если это ожидаемое состояние приложения, то все должно быть в основном 200 с телом ответа, содержащим причину сбоя, а не с ожидаемым объектом ответа, потому что выполнение блока catch является дорогой операцией. Мне лично не нравится такой подход, потому что разработчик вашего API должен проверить сущность ответа и попытаться десериализовать его в ожидаемый объект или, если это не удастся, десериализовать его в некоторый известный объект исключения, потому что это всегда 200.

TLDR: Моя проблема в том, что я вижу много статей о том, почему выполнение блоков catch может быть дорогостоящим в зависимости от трассировки стека, и что обработка ошибок не должна быть частью потока управления, но мне трудно согласиться с этим, потому что Spring имеет функциональность как @ControllerAdvice, @ExceptionHandler или более новая ResponseStatusException. Я также не согласен с аргументом, что коды состояния HTTP относятся к протоколу, а 200 означает просто успешную передачу. Если это так, то 401 и 403 должны быть 200, потому что ответ был обработан нормально, у клиента просто не было авторизации или правильной авторизации. Этот аргумент говорит мне, что все должно быть 200 и зачем даже использовать другие коды состояния? Я все еще в начале своей карьеры, поэтому, пожалуйста, прости, если я упускаю что-то очевидное.

Answer 1

Существует целый ряд кодов состояния http, которые следует использовать при правильном сценарии. На мой взгляд 200 (Http.OK) следует использовать только для успешного ответа. Если вы делаете POST, я обычно делаю 201, поскольку это означает Http.Created. В случае ошибки вы можете сделать Http.UNATHORISED (400) или любую из серий 400 и 500, чтобы указать ошибку, а затем вызвать исключение. Это гораздо полезнее, чем бросать 200 каждый раз с последующим исключением. Дядя Боб в чистом коде говорит, что вы всегда должны выдавать исключение, а не просто код состояния, чтобы ваше мышление было в какой-то степени правильным.

Answer 2

клиент делает запрос для пользователя по идентификатору, а сервер не находит пользователя, это 404 или 200 с пустым телом ответа?

В приведенном выше В случае, что вы упомянули, должно быть 200. Вам нужно использовать 404, когда URL не найден. Точно так же во всех ваших API вы можете обрабатывать их обобщенно c способом, положительным - 200 или 201, отрицательным 500. 404 и другими ошибками 4xx, которые вы можете обрабатывать в своих классах @ControllerAdvice или @Exceptional Handler. Иногда мы также используем 4xx в аутентификации / авторизации.

Answer 3

Прежде всего, вы не можете просто пропустить блок try-catch в каждом случае. Если ваш код выдает какое-то исключение, вы должны быть хорошо осведомлены об этих известных исключениях, чтобы полностью обработать непрерывную службу или остановить приложение от непредвиденного поведения. Если вам нужно перехватить или обработать исключения, то поймайте и обработайте их.

Относительно стоимости обработки исключения:

Никогда не пытайтесь писать слишком много бизнес-логи c внутри блока catch. Просто будьте проще и обрабатывайте это. Там нет ничего, чтобы беспокоиться о стоимости. В серверном приложении иногда приходится отслеживать ошибку, перехватывая исключения и записывая соответствующий журнал для этого. Более того, «попробуйте» почти не имеет никаких затрат. Вместо того, чтобы выполнять настройку try во время выполнения, метаданные кода структурируются во время компиляции так, что когда выдается исключение, теперь выполняется относительно дорогая операция обхода стека и проверки наличия каких-либо блоков try, которые могли бы поймайте это исключение.

Касательно кода HttpStatus:

Http не заставит вас применять 200 в качестве успешного кода состояния. Вы также можете использовать 401 или 403 в качестве кода ответа. Http имеет некоторые стандарты. Нравится (400 за плохой запрос, 403 запрещено). Если вы не следите за этим, не навреди. Тем не менее, вы нарушаете стандарты. Например, вы предоставили мне API, который возвращает JSON в качестве ответа. Тем не менее, я ожидаю 200 для моей успешной операции. Если вы установите 401 в качестве кода успеха, мне придется столкнуться с некоторыми дилеммами, чтобы найти проблемы. Так что лучше придерживаться стандартов.