Может ли IllegalStateException использоваться для захвата всех под исключений?

Question

Интересно, является ли использование IllegalStateException в этом сценарии хорошим выбором для разработки API.

Сценарий: У меня есть функция, которая проверяет, правильно ли сформирован документ XML со следующей подписью:

public boolean isXMLDocumentWellFormed(InputStream inXMLDocument)

Эта функция использует следующий фрагмент для загрузки документа XML:

    boolean isXMLDocWellFormed = false;

    // Setup document builder
    DocumentBuilderFactory docBuilderFactory = DocumentBuilderFactory
            .newInstance();

    if (docBuilderFactory == null)
        throw new IllegalStateException(
                "The DocumentBuilderFactory cannot be instanciated");
    try {
        DocumentBuilder docBuilder = docBuilderFactory.newDocumentBuilder();

        // Parse document
        Document doc = docBuilder.parse(inXMLDocument);

        if (doc != null)
            isXMLDocWellFormed = true;

    } catch (ParserConfigurationException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
        throw new IllegalStateException(e);
    } catch (SAXException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
        throw new IllegalStateException(e);
    } catch (IOException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
        throw new IllegalStateException(e);
    }

    return isXMLDocWellFormed;

API разработан, чтобы быть очень простым в использовании. Однако я хотел бы предоставить пользователям API возможность узнать, почему документ XML не может быть проверен (пример: DocumentBuilderFactory не может создать объект DocumentBuilder ), не перегружая их тоннами проверенных исключений, с которыми им придется иметь дело.

Мои опасения по поводу этого дизайна:

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

1. Чтобы узнать, правильно ли сформирован документ XML.
2. В случае, если функция не может вернуть ответ (например, из-за исключения), почему функция не смогла предоставить ответ.

b) Если ответ на a) отрицательный, то какое имя или решение будет наиболее подходящим и почему ?

С уважением,

Answer 1

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

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

Answer 2

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

1. CleanFailureException: запрошенная операция завершилась неудачно, но попытка не имела никаких побочных эффектов.Ожидается, что объект, выдавший исключение, будет в допустимом состоянии с собственной точки зрения, хотя, возможно, он не соответствует некоторым инвариантам, которые может ожидать пользователь класса.Пример: извлечение несуществующего ключа из словаря.Структуры данных словаря могут быть совершенно допустимыми, как словарь, но приложение может ожидать, что оно будет в состоянии, содержащем запрошенный ключ (также возможно, что словарь находится в правильном состоянии, а что-то еще дало приложению неправильный ключ).
2. PartialOperationException: Запрошенная операция не завершена, но, возможно, завершилась до некоторой неизвестной степени.Как и выше, объект, выдавший исключение, вероятно, находится в допустимом состоянии со своей собственной точки зрения, но вызывающий должен будет проверить, находится ли он в состоянии, которое вызывающий абонент посчитает допустимым.
3. StateCorruptException: Запрошенная операция не завершена, и объект, на котором она была предпринята, или какой-либо вложенный объект, похоже, имеет поврежденное состояние.
4. SystemOnFireException: состояние всего и вся в системе следует рассматривать как подозрительное.

Исключение, вызванное чем-то вроде индекса массива вне границ, может попадать в любую из перечисленных выше категорий.Важно не то, что был получен доступ к индексу за пределами границ, а то, что он означает для других объектов.Catch, wrap и rethrow были бы очень полезными шаблонами, так как разрешение исключения в одной из вышеуказанных категорий даст вызывающему абоненту гораздо лучшее представление о том, что с ним делать.

Answer 3

Если это API, который вы разрабатываете, вы должны заключить все исключения в одно главное исключение. Таким образом, вы не потеряете детали реализации. Однако ваш личный вкус может отличаться

Однако я не думаю, что IllegalStateException хорошо здесь подходит. Он очень общий и не объясняет проблему (исключение ввода-вывода - незаконное состояние?). Лучшее решение - создать свой собственный класс Exception и добавить его.

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