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

Не игнорируйте исключения для исключительных и неожиданных ошибок.

Однако, просто отвечая на ваши вопросы, вопрос в конечном итоге субъективен. Ключевой вопрос - подумать, с чем будет легче работать вашим потребителям, и при этом незаметно подтолкнуть их не забывать проверять условия ошибок. На мой взгляд, это почти всегда «Вернуть код состояния и поместить значение в отдельную ссылку», но это полностью личное мнение каждого человека. Мои аргументы в пользу этого ...

1. Если вы решите вернуть смешанное значение, значит, вы перегрузили концепцию возврата, чтобы она означала «Либо полезное значение , либо код ошибки». Перегрузка одного семантического понятия может привести к путанице в том, что с ним делать.
2. Вы часто не можете легко найти значения в кодомене функции, которые можно использовать в качестве кодов ошибок, и поэтому необходимо смешивать и сопоставлять два стиля сообщений об ошибках в одном API.
3. Почти нет шансов, что, если они забудут проверить статус ошибки, они будут использовать код ошибки, как если бы это был действительно полезный результат. Можно вернуть код ошибки и вставить некоторую нулевую концепцию в возвращаемую ссылку, которая легко взорвется при использовании. Если используется модель смешанного возврата «ошибка / значение», очень легко передать ее в другую функцию, в которой ошибочная часть совместной области является допустимым вводом (но бессмысленным в контексте).

Аргументами в пользу возврата модели смешанного кода / значения ошибки может быть простота - например, никаких дополнительных переменных. Но для меня опасность хуже, чем ограниченный выигрыш - можно легко забыть проверить коды ошибок. Это один из аргументов в пользу исключений - вы буквально не можете забыть обработать их (ваша программа загорится, если вы этого не сделаете).

boost optional - блестящая техника. Пример поможет.

Допустим, у вас есть функция, которая возвращает значение типа double, и вы хотите указать на ошибку, если ее невозможно вычислить.

double divide(double a, double b){
    return a / b;
}

что делать в случае, когда b равно 0;

boost::optional<double> divide(double a, double b){
    if ( b != 0){
        return a / b;
    }else{
        return boost::none;
    }
}

используйте его, как показано ниже.

boost::optional<double> v = divide(a, b);
if(v){
    // Note the dereference operator
    cout << *v << endl;
}else{
    cout << "divide by zero" << endl;
}

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

template <typename T>
T f( const T & t ) {
   if ( SomeFunc( t ) ) {
      return t;
   }
   else {         // error path
     return ???;  // what can we return?
   }
}

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

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

Хотя я симпатизирую этому мнению, я считаю, что первое обычно лучше работает на практике. С одной очевидной точки зрения, в первом случае вы можете связать назначение с произвольным количеством получателей, но во втором, если вам нужно / вы хотите назначить результат более чем одному получателю, вы должны выполнить вызов, а затем отдельно сделать второе задание. Т.е.,

 account1.rate = account2.rate = current_rate();

vs.:

set_current_rate(account1.rate);
account2.rate = account1.rate;

or:

set_current_rate(account1.rate);
set_current_rate(account2.rate);

Доказательство пудинга - его поедание. COM-функции Microsoft (например) выбрали исключительно последнюю форму. ИМО, именно благодаря этому решению по существу весь код, который напрямую использует собственный COM API, уродлив и почти нечитаем. Используемые концепции не особенно сложны, но стиль интерфейса превращает то, что должно быть простым кодом, в почти нечитаемый беспорядок практически во всех случаях.

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

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

Другой метод C, который я вижу, - это возвращать 0 в случае успеха, а в случае ошибки возвращается -1, а errno устанавливается для указания ошибки.

Каждый из представленных вами методов имеет свои плюсы и минусы, поэтому решение о том, какой из них «лучший», всегда будет (по крайней мере частично) субъективным. Однако я могу сказать это без оговорок: лучшая техника - это техника, которая единообразна во всей вашей программе. Использование разных стилей кода сообщения об ошибках в разных частях программы может быстро превратиться в кошмар при обслуживании и отладке.

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

При использовании C ++ существует гораздо больше возможностей, чем эти два, включая исключения и использование чего-то вроде boost :: optional в качестве возвращаемого значения.

C традиционно использовал первый подход к кодированию магических значений в действительных результатах - вот почему вы получаете забавные вещи, такие как strcmp (), возвращающий false (= 0) при совпадении.

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

И никакие исключения здесь не альтернатива. Исключения предназначены для исключительных обстоятельств, с которыми код может не справиться - вы не вызываете исключение для строки, не соответствующей в strcmp ()

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

• Вместо того, чтобы передавать имя файла глубоко во многих вызовах функций, вы можете разработать свою программу так, чтобы вызывающая сторона открывала файл и передавала FILE * или дескриптор файла. Это исключает проверки на «не удалось открыть файл» и сообщать об этом вызывающей стороне на каждом этапе.

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

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

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

Для C ++ я предпочитаю шаблонное решение, которое предотвращает непостоянство параметров и непостоянства «магических чисел» в комбинированных ответах / кодах возврата. Я изложил это, отвечая на еще вопрос. Посмотри.

Что касается C, я считаю, что ускользающие параметры менее оскорбительны, чем ускользающие «магические числа».

Вы пропустили метод: возврат сообщения об ошибке и необходимость дополнительного вызова для получения сведений об ошибке.

Об этом можно много сказать.

Пример:

int count;
if (!TryParse("12x3", &count))
  DisplayError(GetLastError());

редактировать

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

HKEY key;
long errcode = RegOpenKey(HKEY_CLASSES_ROOT, NULL, &key);
if (errcode != ERROR_SUCCESS)
  return DisplayError(errcode);

Сравните это с:

HKEY key;
if (!RegOpenKey(HKEY_CLASSES_ROOT, NULL, &key))
  return DisplayError(GetLastError());

(Версия GetLastError согласуется с тем, как в целом работает Windows API, но версия, которая возвращает код напрямую, работает именно так, поскольку API реестра не соответствует этому стандарту.)

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

HKEY key;
if (RegOpenKey(HKEY_CLASSES_ROOT, NULL, &key) != ERROR_SUCCESS)
  return DisplayGenericError();

редактировать

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

Для универсального API в стиле C, такого как функции Windows SDK, которые я использовал в своих примерах, нет неглобального контекста для кодов ошибок. Вместо этого у нас нет хорошей альтернативы использованию глобального TLV. что можно проверить после сбоя.

Однако, если мы расширим тему, включив в нее методы класса, ситуация изменится. Совершенно разумно, учитывая переменную reg, которая является экземпляром класса RegistryKey, для вызова reg.Open, чтобы вернуть false, требуя затем вызвать reg.ErrorCode для получения деталей.

Я считаю, что это удовлетворяет запрос R. о том, чтобы код ошибки был частью контекста, поскольку экземпляр предоставляет контекст. Если вместо экземпляра RegistryKey мы вызвали статический метод Open на RegistryKeyHelper, то получение кода ошибки при сбое также должно быть статическим, что означает, что это должен быть TLV, хотя и не полностью глобальный. Класс, в отличие от экземпляра, будет контекстом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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