White Owl
MasterZivКоды возврата же накладывают два дополнительных ограничения:
каждая функция должна принимать дополнительный параметр для возврата кода ошибки или должна не быть функцией (возвращаемое значение будет кодом возврата).
Это не обязательно. Вспомни хоть о libc с его errno и WinAPI с GetLastError().
.

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

White OwlMasterZiv после вызова каждой функции надо проверять код возврата. При каскадном вызове функций -- при каждом вложенном вызове.
Это тоже не обязательно. Очень часто функция может возвращать много информационных кодов которые можно игнорировать. Да и часто бывает что несколько родственных функций запускается подряд и падение второй функции в цепочке невозможно если отработала первая. Как пример fopen()-fread(), если мы файл сумели открыть, мы всегда сумеем его прочитать (уже другое дело сколько именно байт мы прочитаем), но fread() упасть просто не сможет.
Во всех этих случаях, коды возврата можно запросто игнорировать. А при работе с исключениями эта проверка будет всегда, ее компилятор насильно в твой код впихнет.
.

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

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

Если функция не завершается аварийно, то очевидно, что и говорить не о чем -- не будет либо исключений, либо кодов возврата.


White OwlУгу. А как быть с информационными сообщениями? Тот же SQL_SUCCESS_WITH_INFO если ты делаешь враппер для ODBC? Делать такие возвраты как исключения или как коды возврата в дополнение к исключениям которые будут перекрывать SQL_ERROR?

И перевирая твои слова: Ну очевидно же, что кода возврата более гибкие.

Я объяснял, как надо поступать с диагностикой из ODBC и подобных библиотек. (в отдельной теме было)
Это не исключения и не коды возврата, это дополнительный поток данных с диагностикой из источника данных.
Иногда эти данные означают, что операция завершилась аварийно, тогда, только в этих случаях нужно генерировать исключение или плохой код возврата.

Итого, тут нет доводов ни за исключения, ни против.

Владимир20122787Хотел бы поделиться своим подходом ...
Конечно он не идеален, но много упрощает анализ результата выполнения функции.

Над всеми libraries, которые использую создаю wrapper classes.
Зачем?
Их назначение одно - они инкапсулируют обработку результата выполнения функции.
В результате анализ результата выполнения функции сводится к анализу member m_Ok.
Если он не имеет значения TRUE, то анализируем значение m_LastErrorCode


Вредный подход.
Ты мог бы писать такие врапера (функции, не классы), обрабатывать исключительные случаи,
и выбрасывать исключения в нужных местах, где уже сохранять и код возврата, и причину
ошибки. Вот это было бы по-C++-ному.

Владимир2012MasterZivВредный подход.
Ты мог бы писать такие врапера (функции, не классы), обрабатывать исключительные случаи,
и выбрасывать исключения в нужных местах, где уже сохранять и код возврата, и причину
ошибки. Вот это было бы по-C++-ному. Кто нам мешает все это сделать в wrapper при вызове функции и затем произвести анализ на
наличие ошибки или исключения в месте вызова этой функции?

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