Исключение по сравнению с кодом ошибки по сравнению с утверждает

assert не является правильным выбором. Используйте assert, когда у вас есть инвариант; то, что никогда не должно случиться. Не делайте таких вещей, как assert (), что аргумент никогда не будет нулевым, если это условие ошибки, а не инвариант.

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

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

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

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

Я рекомендую прочитать руководство сообщества Boost [boost.org] по исключениям и обработке ошибок.

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

Насколько надежны устройства, о которых вы сообщаете?

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

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

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

На самом деле не имеет значения, что такие «исключения» на самом деле просто причудливый способ закодировать if (x! = 0) {goto error_routine; }, но я лично предпочитаю обработку исключений для работы с исключительными ситуациями, а не с обычными событиями, такими как end_of_file.

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

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

#ifdef __cplusplus__
void generate_report(const std::string& rep_number, ostream& output);

extern "C" 
#endif
int generate_report(const char* rep_number, const char* outputfilename,
                    int* error_code, char* error_text, int max_error_text_len);

Реализация C вызывает реализацию C ++:

extern "C" 
int generate_report(const char* rep_number, const char* outputfilename,
                    int* error_code, char* error_text, int max_error_text_len)
{
    ofstream os;
    try {
        os.open(outputfilename, IOS_WRITE);
        generate_report(rep_number, os);
        os.close();
        return TRUE;
    } catch (base_exception& e) {
        os.close();
        if (error_code) *error_code = e.error_code();
        if (error_text) strncpy(error_text, e.str(), max_error_text_len);
        return FALSE;
    }
}

Первое - будьте последовательны!

Второе:

• просто истина / ложь недостаточно. Он должен сочетаться с кодами ошибок (например, false + getLastError).
• коды ошибок работают быстро, но необходимо создать некоторую инфраструктуру, чтобы легко преобразовывать их в строки.
• assert / log: нет, вы хотите, чтобы приложение выполняло иметь возможность реагировать на ошибку.
• исключения работают медленнее, чем коды ошибок, но их легче программировать со сложным потоком управления.
• комбинации: комбинируются только истинные / ложные + коды ошибок, в остальном СОГЛАСОВАНЫ , что означает: не комбинировать.

• следует использовать ведение журнала, если у вас нет доступа к терминалу для создания / чтения отчетов об ошибках.
• , возвращающий True / False, должен сочетаться с кодами ошибок. Пример: функция возвращает True в случае успеха, False в случае ошибки и устанавливает переменную (глобальную или параметр, по вашему выбору) с соответствующим кодом / описанием ошибки.
• исключения: на мой взгляд, хорошо сочетать их с ведением журнала и плавное восстановление после ошибок. Если это невозможно, вы также можете прибегнуть к кодам ошибок, так как исключения не дают дополнительных преимуществ.
• assert (): Как отмечали другие, он компилируется при выпуске сборок, поэтому запускайте по желанию.

2c

У любого из них разные цели:

• код ошибки верс. Исключение (я): исключения и коды ошибок представляют разные идиомы того, как обрабатывать коды результатов. Исключения более надежны - коды результатов можно игнорировать или терять. Библиотека обычно должна четко различать, где и какие исключения выбрасываются и когда используются коды ошибок. В лучшем случае используйте только один из них.

• return true или false : специализация кодов ошибок. Библиотека обычно должна четко различать, где и какие исключения выбрасываются и когда используются коды ошибок. В лучшем случае используйте только один из них.

• return true или false : специализация кодов ошибок. Библиотека обычно должна четко различать, где и какие исключения выбрасываются и когда используются коды ошибок. В лучшем случае используйте только один из них.

• return true или false : специализация кодов ошибок. Usually the worst idea - only good if there is no more to report than good or bad (i.e. malloc returns either good or bad (= NULL).

• assert and log: These are debugging techniques, and should not be used as report mechanisms to users / clients. Asserts just say "something happened, that I can not handle - I quit".