переупаковывать исключения или сохранять их нетронутыми?

Question

Я пишу некоторый класс, который имеет 2 (основные) подсистемы. Часть зависит от boost :: filesystem, а другая часть зависит от tinyxml. (По сути, он читает XML и, в зависимости от данных XML, использует функции boost::filesystem для большего доступа к другим файлам).

Теперь оба они "могут" генерировать исключения. Мне интересно, как обрабатывать эти исключения:

Сам класс - в большинстве случаев - не может "исправить" исключение и должен просто отбросить его. (Наиболее вероятный случай - неверный ввод от пользователя).

Но что делать в таком случае? - boost::filesystem и tinyxml имеют свои исключения, которые не полностью совместимы друг с другом.

Стоит ли ожидать от пользователя этого класса обработки исключений boost / tinyxml? - Пока все использование этих библиотек скрыто для конечного пользователя.

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

Что вы мне порекомендуете?

Answer 1

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

Answer 2

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

Но если ваши правила кодирования допускают исключения, тогда я предлагаю общее правило:

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

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

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

Answer 3

Считаете ли вы, что это актуально для конечного пользователя?Потому что это связано с дизайном.

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

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

Claudio.