Какая школа отчетности о сбоях функций лучше

Question

Очень часто у вас есть функция, которая для заданных аргументов не может генерировать действительный результат или не может выполнять некоторые задачи.Помимо исключений, которые не так часто используются в мире C / C ++, в основном есть две школы сообщения о недопустимых результатах.

Первый подход смешивает допустимые возвращаемые значения со значением, которое не принадлежит кодомену функцииочень часто -1) и указывает на ошибку

int foo(int arg) {
    if (everything fine)
        return some_value;
    return -1; //on failure
}

Подход scond заключается в возврате состояния функции и передаче результата в пределах ссылки

bool foo(int arg, int & result) {
     if (everything fine) {
         result = some_value;
         return true;
     }
     return false;  //on failure
}

Какой способ вы предпочитаете и почему,Приносит ли дополнительный параметр во втором методе ощутимые потери производительности?

Answer 1

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

Answer 2

Для функции "try", где разумно ожидается некоторый "нормальный" тип отказа, как насчет принятия либо возвращаемого по умолчанию значения, либо указателя на функцию, которая принимает определенные параметры, связанные с ошибкой, и возвращает такое значение ожидаемый тип?

Answer 3

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

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

Приносит ли дополнительный параметр во втором методе ощутимые потери производительности?

Да!Дополнительные параметры приводят к замедлению вашего компьютера по крайней мере на 0 наносекунд.Лучше всего использовать ключевое слово «no-overhead» для этого параметра.Это расширение GCC __attribute__((no-overhead)), поэтому YMMV.

Answer 4

Я предпочитаю использовать код возврата для типа возникшей ошибки.Это помогает вызывающей стороне API предпринять соответствующие шаги обработки ошибок.

Рассмотрим API-интерфейсы GLIB, которые чаще всего возвращают код ошибки и сообщение об ошибке вместе с логическим возвращаемым значением.получить отрицательный возврат к вызову функции, вы можете проверить контекст из переменной GError.

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

Answer 5

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

Answer 6

Если у вас есть ссылки и тип bool, вы должны использовать C ++.В этом случае выведите исключение.Вот для чего они.Для обычной рабочей среды нет причин использовать коды ошибок.Я видел аргументы против исключений в некоторых средах, таких как хитрое взаимодействие язык / процесс или жесткая встроенная среда.Предполагая, что ни один из них не всегда выдает исключение.

Answer 7

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