openlang
Отладка и наблюдаемость

Обёртка исключения без потери причины

Разговор продолжается 3 ↓Посмотреть источники ↓

Стоит инструменту импорта перехватить низкоуровневый сбой и заменить его, как в диагностическом журнале остаётся только new ImportFailure("Import failed"). Вызывающему коду незачем видеть сведения о локальных файлах. Но тому, кто разбирает сбой, нужно понять, что на самом деле пошло не так.

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

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

Богатая диагностика тянет за собой правила доступа и маскирования, и эта цена вполне ощутима. Если выбросить причину, этой работы не будет, зато расследовать придётся по двум словам. Я бы выбрал маскирование.

Разговор продолжается 3

Следуя доводам
  1. Ссылка на ответ

    Две проверки, по очереди. Сначала убедимся, что getCause() у обёртки возвращает исходный сбой. Когда это так, собираем публичный ответ из доменной категории и сообщение причины вообще не читаем.

    Потом кладём /example/private/input.csv в исходное сообщение и проверяем, что в ответе этого пути нет. С ответом на этом всё. Запись в журнале уходит в другое место и содержит свои поля, а этот тест ничего не говорит о том, какие из них можно показывать. Журналирование придётся разобрать само по себе.

  2. Ссылка на ответ

    Можете выложить только создание обёртки и вызов журналирования для одного сбоя? Сама по себе прикреплённая причина в журнал ничего не добавляет, так что начну со строки журналирования. Подставьте фиктивный путь и посмотрите по очереди на запись в журнале и на публичный ответ. На таком маленьком примере видно, где пропадают сведения.

  3. Ссылка на ответ

    Cocoa давно решила это через NSUnderlyingErrorKey. Возвращаемая NSError уровня предметной области хранит ошибку нижнего уровня в userInfo под этим ключом, localizedDescription пишется для человека, читающего сообщение, а исходная ошибка остаётся доступной тому, кто сознательно её журналирует.

    Но осторожность нужна та же. Записать в журнал весь словарь userInfo это вариант печати всех значений исключений на Objective-C, и туда охотно попадёт путь к файлу, который вы хотели скрыть.