Обертка проверенного исключения в исключение без исключения в Java?

У меня есть этот метод factory в java:

public static Properties getConfigFactory() throws ClassNotFoundException, IOException {
    if (config == null) {
        InputStream in = Class.forName(PACKAGE_NAME).getResourceAsStream(CONFIG_PROP);
        config = new Properties();
        config.load(in);
    }
    return config;
}

И я хочу преобразовать два проверенных исключения в непроверенные исключения. Каков наилучший способ сделать это?

Должен ли я просто поймать исключение и выкинуть новое RuntimeException, используя исключение catch в качестве внутреннего исключения?

Есть ли лучший способ сделать это, или я должен вообще попытаться это сделать?

EDIT:
Просто для уточнения. Эти исключения будут фатальными, поскольку файл конфигурации по существу относится к работе программы, и все исключения будут пойманы и записаны на верхний уровень моей программы.

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

Ответ 1

A RuntimeException следует использовать только тогда, когда клиент не может восстановиться из любой проблемы. Иногда бывает целесообразно делать то, о чем вы говорите, но чаще это не подходит.

Если вы используете JDK >= 1.4, вы можете сделать что-то вроде:

try {
  // Code that might throw an exception
} catch (IOException e) {
  throw new RuntimeException(e);
} catch (ClassNotFoundException e) {
  throw new RuntimeException(e);
}

а возвращаемый RuntimeException будет иметь исходную причину, включенную внутри него. Таким образом, кто-то в верхней части потока, ловит RuntimeException - ваши потоки поймают RuntimeException, чтобы они не просто молча умирали, не так ли? - может, по крайней мере, распечатать FULL трассировку стека причины.

Но, как говорили и скажут другие, исключения проверяются по какой-то причине. Делайте это только тогда, когда вы уверены, что ваши клиенты не могут оправиться от проблемы, которую вы перестраиваете как исключение.

ПРИМЕЧАНИЕ. Лучше, чем просто RuntimeException использовать более конкретное исключение, если оно доступно. Например, если единственная причина, по которой ваш метод может выкинуть ClassNotFoundException, - это потому, что отсутствует файл конфигурации, вы можете переделать MissingResourceException, который является неконтролируемым исключением, но дает больше информации о том, почему вы его бросаете. Другим хорошим RuntimeException для использования, если они описывают проблему, которую вы перестраиваете, являются IllegalStateException, TypeNotPresentException и UnsupportedOperationException.

Также обратите внимание, что ВСЕГДА хорошая идея для ваших потоков поймать RuntimeException и, как минимум, занести в журнал. По крайней мере, таким образом вы понимаете, почему ваши потоки уходят.

Ответ 2

Здесь - хорошая компиляция лучших практик обработки исключений.

Два пункта оттуда:

Код вызывающего абонента ничего не может сделать об исключении → Сделать это непроверенным исключением
Код вызывающего абонента предпримет некоторые полезные действия по восстановлению на основе информации в исключении → Сделайте это проверенным исключением

И вы можете бросить RuntimeException с внутренним исключением или без него, в зависимости от того, что вызывающий может с ним сделать. Если вы не восстанавливаете внутреннее исключение, вы должны занести его в свой метод, если это важно.

Ответ 3

Вы делаете это правильно.

Чтобы исключить проверенные исключения, не проверяя их, вы должны обернуть их в незарегистрированные исключения.

Просто помните, Исключения проверяются по какой-либо причине.

Ответ 4

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

Вы должны обрабатывать исключения, здесь или где-то еще.

И поскольку это factory, мне кажется, что эти исключения обрабатываются самим factory (таким же методом или другим методом) и возвращают реализацию по умолчанию.

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