Исключения и коды ошибок: правильное их смешивание

Question

Я занимаюсь разработкой библиотеки для общения с C ++ ключом.Библиотека предоставит унифицированный интерфейс для связи с различными удаленными ключами исполнения кода, такими как SenseLock, KEYLOK, Guardant Code.

Ключи основаны на технологии смарт-карт и имеют внутреннюю файловую систему и оперативную память.

Типичная рабочая процедура включает в себя (1) перечисление ключей, подключенных к USB-портам, (2) подключение к выбранному ключу, (3) выполнение именованного модуля, передающего входные данные и собирающего выходные данные.

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

• Ключ не найден (конечно, смертельный случай).
• Ошибка соединения с ключом (смертельный случай).
• Указанный исполняющий модуль не найден в ключе (?).
• Запрошенная операция не выполнена из-за тайм-аута (?).
• Запрошенная операция требует авторизации (подлежит восстановлению)случай, я полагаю).
• Произошла ошибка памяти при выполнении модуля в ключе (обязательно фатальный случай).
• Произошла ошибка файловой системы в ключе (конечно фатальный случай).

?- Я пока не знаю, считается ли дело фатальным.

Я все еще решаю, создавать ли исключения, возвращать коды ошибок или реализовывать методы для обоих случаев.

Вопросы:

1. Заменяют ли исключения коды ошибок полностью или, может быть, мне нужно использовать их только для "смертельных случаев"?
2. Является ли смешивание двух парадигм (исключений и кодов ошибок) хорошей идеей?
3. Является ли хорошей идеей предоставить пользователю две концепции?
4. Существуют ли хорошие примеры исключений и кодов ошибок?Концепция смешивания?
5. Как бы вы это реализовали?

Обновление 1.

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

Answer 1

Заменяют ли исключения коды ошибок полностью или, может быть, мне нужно использовать их только для "смертельных случаев"?

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

• EINTR: операция прервана, иногда стоит перезапустить операцию, а иногда это означает, что «пользователь хочет выйти из программы»
• EWOULDBLOCK: операция неблокирующая, но данные не могут быть переданы сейчас.Если вызывающий ожидает надежного неблокирующего поведения (например, доменные сокеты UNIX), это фатальная ошибка.Если вызывающая сторона выполняет оппортунистическую проверку, это пассивный успех.
• частичный успех: в контексте потоковой передачи (например, TCP, дисковый ввод-вывод) ожидаются частичные операции чтения / записи.В отдельном контексте обмена сообщениями (например, UDP) частичное чтение / запись может указывать на фатальное усечение.

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