Классы множественного исключения не похожи на избыточные, особенно когда мы используем коды ошибок?

Question

Я использую Spring Boot и Spring Rest в нашем приложении.

Мой запрос : в нашем приложении мы используем коды ошибок, а также создаем классы множественных исключений. Итак, когда мы уже используем пользовательские коды ошибок, какой смысл снова создавать классы множественных исключений? Я думаю, что нужно создать только один класс пользовательских исключений для всего приложения (скажем, AppException), должно быть достаточно для отображения ответа об ошибке для всех видов сценариев ошибок ios с использованием кодов ошибок.

Хорошо, даже для журналов мы можем показать то же исключение (ie., AppException), а также отобразить код ошибки в самом журнале. Поэтому, когда возникает любое RunTimeException, просматривая коды ошибок и соответствующие сообщения об ошибках в журналах, мы узнаем, какова действительная причина, верно?

Итак, Наличие классов множественных исключений не как избыточный, особенно когда мы используем коды ошибок?

Пожалуйста, подумайте, если я ошибаюсь.

РЕДАКТИРОВАТЬ: К вашему сведению ниже мое CustomException, которое принимает код ошибки в качестве параметра

import java.util.Arrays;

public class MyAppException extends RuntimeException {
    private final MyAppErrorCodes errorCode;
    private final Object[] errorCodeArgs;

    public MyAppException(final MyAppErrorCodes errorCode, final Throwable cause, final Object... args) {
        super(cause);
        this.errorCode = errorCode;
        this.errorCodeArgs = Arrays.copyOf(args, args.length);
    }

    public MyAppErrorCodes getErrorCode() {
        return errorCode;
    }

    public Object[] getErrorCodeArgs() {
        return errorCodeArgs.clone();
    }
}

Answer 1

Использование обоих может быть приемлемым по некоторым причинам.

Использование нескольких исключений в большинстве случаев лучше для обработки ошибок системой, потому что java обрабатывает ее (try-catch).

Использование кодов ошибок теперь может быть интересным для вызывающей стороны ... представьте, что вы хотите быть в курсе причин ошибки. За все неправильные данные вы вернете 400 ошибочных запросов ... но вы можете дополнить свои ответы кодом ошибки бизнеса.

Пример:

• Http 400, код ошибки 001 ( требуется фамилия)
• Http 400, код ошибки 002 (слишком длинная фамилия) ...

Для стороны вызывающего абонента будет просто интерпретировать коды ошибок вместо сообщений об ошибках

Это именно то, как мы добавляем детали ошибки с SOAP.

Код ошибки также интересен, чтобы обогатить сообщения журнала для дальнейшей отладки.

Итак, что касается вашего вопроса:

Итак, классы с несколькими исключениями не похожи на избыточные особенно если мы используем коды ошибок?

Нет. Использование обоих может быть полностью оправдано.

Answer 2

Если у вас есть обобщенное c приложение-исключение, например,

class ApplicationException extends Exception {
  ...
  private int errorCode; // with getter and setter
}

, реальное значение ситуации исключения закодировано в ApplicationException.errorCode, например, 4839238756

Это только что-то значит для разработчика, я думаю, и, возможно, относится к очень специфическому c состоянию ошибки, например, cannot create new resource

. Вы можете извлечь значение на более высокий уровень и использовать несколько классов исключений, например,

class ResourceException extends ApplicationException {
  ...
}

class NetworkException extends ApplicationException {
  ...
}

проблемы затем классифицируются на отдельные области функциональности в приложении и могут регистрироваться в различных файлах журнала проблем. Указанная причина c все еще может быть закодирована в errorCode.

Это то, хотите ли вы обрабатывать исключения далее по цепочке, например, иметь отдельные файлы журнала для различных типов исключений, таких как ошибки базы данных, сетевые ошибки et c, вместо того, чтобы выяснить, к какому типу исключений относятся его errorCode.

Разработчик, которому необходимо исправить сетевые исключения, может сосредоточиться на них, поскольку только те, которые зарегистрированы в issues.network.log для пример, и каждый errorCode будет сужать его дальше, но в контексте этого типа исключения.

Если вы входите в базу данных, вы можете запросить все NetworkException с, а не диапазон errorCode, например, все errorCode между 234342 и 898987, если вы разделяете errorCode на функциональные области.