Лучший способ определить коды ошибок / строки в Java?

Я пишу веб-службу на Java и пытаюсь найти лучший способ определения кодов ошибок и связанных с ними строк ошибок . Мне нужно сгруппировать числовой код ошибки и строку ошибки. И код ошибки, и строка ошибки будут отправлены клиенту, обращающемуся к веб-службе. Например, при возникновении SQLException я могу сделать следующее:

// Example: errorCode = 1, 
//          errorString = "There was a problem accessing the database."
throw new SomeWebServiceException(errorCode, errorString);

Клиентской программе может быть показано сообщение:

«Произошла ошибка №1: возникла проблема с доступом к базе данных».

Моя первая мысль заключалась в том, чтобы использовать один Enumиз кодов ошибок и переопределить toStringметоды для возврата строк ошибок. Вот что я придумал:

public enum Errors {
  DATABASE {
    @Override
    public String toString() {
      return "A database error has occured.";
    }
  },

  DUPLICATE_USER {
    @Override
    public String toString() {
      return "This user already exists.";
    }
  },

  // more errors follow
}

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

Ну, безусловно, есть лучшая реализация решения enum (что в целом довольно приятно):

public enum Error {
  DATABASE(0, "A database error has occured."),
  DUPLICATE_USER(1, "This user already exists.");

  private final int code;
  private final String description;

  private Error(int code, String description) {
    this.code = code;
    this.description = description;
  }

  public String getDescription() {
     return description;
  }

  public int getCode() {
     return code;
  }

  @Override
  public String toString() {
    return code + ": " + description;
  }
}

Возможно, вы захотите переопределить toString (), чтобы вместо этого просто возвращать описание - не уверен. В любом случае, главное, что вам не нужно переопределять отдельно для каждого кода ошибки. Также обратите внимание, что я явно указал код вместо использования порядкового номера - это упрощает изменение порядка и добавление / удаление ошибок позже.

Не забывайте, что это вообще не интернационализировано, но если ваш клиент веб-службы не отправит вам описание локали, вы все равно не сможете легко интернационализировать его самостоятельно. По крайней мере, у них будет код ошибки, который будет использоваться для i18n на стороне клиента ...

Насколько мне известно, я предпочитаю выводить сообщения об ошибках в файлы свойств. Это будет действительно полезно в случае интернационализации вашего приложения (один файл свойств на каждый язык). Также проще изменить сообщение об ошибке, и для этого не потребуется повторная компиляция исходных текстов Java.

В моих проектах, как правило, у меня есть интерфейс, содержащий коды ошибок (строковые или целые числа, это не важно), который содержит ключ в файлах свойств для этой ошибки:

public interface ErrorCodes {
    String DATABASE_ERROR = "DATABASE_ERROR";
    String DUPLICATE_USER = "DUPLICATE_USER";
    ...
}

в файле свойств:

DATABASE_ERROR=An error occurred in the database.
DUPLICATE_USER=The user already exists.
...

Еще одна проблема с вашим решением - это ремонтопригодность: у вас всего 2 ошибки и уже 12 строк кода. Итак, представьте свой файл перечисления, когда вам придется управлять сотнями ошибок!

Перегрузка toString () кажется немного неприятной - это немного похоже на обычное использование toString ().

Что о:

public enum Errors {
  DATABASE(1, "A database error has occured."),
  DUPLICATE_USER(5007, "This user already exists.");
  //... add more cases here ...

  private final int id;
  private final String message;

  Errors(int id, String message) {
     this.id = id;
     this.message = message;
  }

  public int getId() { return id; }
  public String getMessage() { return message; }
}

мне кажется намного чище ... и менее многословным.

На последней работе я немного углубился в версию enum:

public enum Messages {
    @Error
    @Text("You can''t put a {0} in a {1}")
    XYZ00001_CONTAINMENT_NOT_ALLOWED,
    ...
}

@Error, @Info, @Warning сохраняются в файле класса и доступны во время выполнения. (У нас была пара других аннотаций, которые также помогают описать доставку сообщений)

@Text - это аннотация времени компиляции.

Я написал для этого обработчик аннотаций, который делал следующее:

• Убедитесь, что нет повторяющихся номеров сообщений (часть перед первым подчеркиванием)
• Синтаксис - проверьте текст сообщения
• Создайте файл messages.properties, содержащий текст с ключом из значения перечисления.

Я написал несколько служебных программ, которые помогали регистрировать ошибки, оборачивать их как исключения (при желании) и так далее.

Я пытаюсь убедить их разрешить мне открыть его исходный код ... - Скотт

Я бы рекомендовал вам взглянуть на java.util.ResourceBundle. Вы должны заботиться о I18N, но оно того стоит, даже если вы этого не сделаете. Вынесение сообщений во внешний вид - очень хорошая идея. Я обнаружил, что было полезно иметь возможность предоставлять деловым людям электронную таблицу, которая позволяла им использовать именно тот язык, который они хотели видеть. Мы написали задачу Ant для создания файлов .properties во время компиляции. Это делает I18N тривиальным.

Если вы также используете Spring, тем лучше. Их класс MessageSource полезен для такого рода вещей.

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

Есть много способов решить эту проблему. Я предпочитаю иметь интерфейсы:

public interface ICode {
     /*your preferred code type here, can be int or string or whatever*/ id();
}

public interface IMessage {
    ICode code();
}

Теперь вы можете определить любое количество перечислений, которые предоставляют сообщения:

public enum DatabaseMessage implements IMessage {
     CONNECTION_FAILURE(DatabaseCode.CONNECTION_FAILURE, ...);
}

Теперь у вас есть несколько возможностей превратить их в строки. Вы можете скомпилировать строки в свой код (используя аннотации или параметры конструктора перечисления), или вы можете прочитать их из файла конфигурации / свойств, из таблицы базы данных или смеси. Последний вариант - мой предпочтительный подход, потому что вам всегда будут нужны некоторые сообщения, которые вы можете очень быстро преобразовать в текст (т.е. пока вы подключаетесь к базе данных или читаете конфигурацию).

Я использую модульные тесты и фреймворки отражения, чтобы найти все типы, реализующие мои интерфейсы, чтобы убедиться, что каждый код где-то используется и что файлы конфигурации содержат все ожидаемые сообщения и т. Д.

Используя фреймворки, которые могут анализировать Java, например https://github.com/javaparser/javaparser или Eclipse , вы даже можете проверить, где используются перечисления, и найти неиспользуемые.

Я (и остальная часть нашей команды в моей компании) предпочитаю создавать исключения вместо того, чтобы возвращать коды ошибок. Коды ошибок необходимо везде проверять, передавать и делать код нечитаемым, когда количество кода становится больше.

Затем класс ошибки будет определять сообщение.

PS: а собственно еще и забота об интернационализации!
PPS: вы также можете переопределить метод повышения и при необходимости добавить ведение журнала, фильтрацию и т. Д. (По крайней мере, в средах, где классы исключений и их друзья расширяются / изменяются)

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

public enum Error {
    DATABASE(0, "A database error has occured. "), 
    DUPLICATE_USER(1, "User already exists. ");
    ....
    private String description = "";
    public Error changeDescription(String description) {
        this.description = description;
        return this;
    }
    ....
}

Error genericError = Error.DATABASE;
Error specific = Error.DUPLICATE_USER.changeDescription("(Call Admin)");

РЕДАКТИРОВАТЬ: хорошо, использование перечисления здесь немного опасно, поскольку вы постоянно меняете конкретное перечисление. Я думаю, лучше было бы перейти на класс и использовать статические поля, но вы больше не можете использовать '=='. Думаю, это хороший пример того, чего не следует делать (или делать это только во время инициализации) :)

enum для определения кода ошибки / сообщения по-прежнему является хорошим решением, хотя у него есть проблемы с i18n. Фактически у нас может быть две ситуации: код / ​​сообщение отображается конечному пользователю или системному интегратору. В последнем случае I18N не нужен. Я думаю, что веб-сервисы - это, скорее всего, более поздний случай.

С помощью interface качестве константы сообщения обычно плохая идея. Он будет постоянно попадать в клиентскую программу как часть экспортируемого API. Кто знает, что более поздние клиентские программисты могут анализировать эти сообщения об ошибках (публичные) как часть своей программы.

Вы будете навсегда заблокированы, чтобы поддерживать это, поскольку изменения в строковом формате могут нарушить работу клиентской программы.

Пожалуйста, следуйте приведенному ниже примеру:

public enum ErrorCodes {
NO_File("No file found. "),
private ErrorCodes(String value) { 
    this.errordesc = value; 
    }
private String errordesc = ""; 
public String errordesc() {
    return errordesc;
}
public void setValue(String errordesc) {
    this.errordesc = errordesc;
}

};

В вашем коде назовите это так:

fileResponse.setErrorCode(ErrorCodes.NO_FILE.errordesc());

Я использую PropertyResourceBundle для определения кодов ошибок в корпоративном приложении для управления ресурсами кода ошибок локали. Это лучший способ обрабатывать коды ошибок вместо написания кода (может быть применим для нескольких кодов ошибок), когда количество кодов ошибок велико и структурировано.

См. Java doc для получения дополнительной информации о PropertyResourceBundle