Является ли std :: error_code хорошим способом выдачи предупреждений?
Я сейчас пользуюсь std::error_code чтобы дать отзыв пользователям моего API, когда что-то пойдет не так. Было бы семантически приемлемо добавить std::error_condition типа warning уведомить моих пользователей, что была незначительная проблема, но что операции продолжатся? Или я должен использовать только логирование для этого?
Решение
Если я правильно понял, вы спрашиваете, считается ли возвращение предупреждения злоупотреблением std::error_code семантика или нет.
Теперь стандарт вводит error_code как часть стандартная библиотека диагностики
[Diagnostics.general] В этом разделе описываются компоненты, которые программы C ++ могут использовать для обнаружения и сообщения об ошибках.
и, насколько я знаю, не предъявляет никаких семантических требований к тому, что такое «условие ошибки», мы можем просто предположить, что они должны использоваться для сообщения о том, что что-то пошло не так, но это не означает, что последствия частичного выполнения спецификации операции должны вам сказать.
Единственное семантическое требование, которое я вижу, состоит в том, что код ошибки (и код ошибки) является логически конвертируемым, то есть «нулевой» код ошибки всегда должен означать успех.
Теперь, учитывая, что вы предположительно хотите, чтобы операция, завершающаяся с предупреждением, считалась успешной, по этой причине Я не считаю правильным возвращать такое предупреждение с помощью кода ошибки;
Тем не менее, вы всегда можете позволить вашей операции вернуться два коды ошибок (по вашему желанию, возможно, принадлежащие к разным категориям), документирующие, что только первая сообщает о выполнении эффектов операции:
auto [err,war] = some_operation();
if(err) call_the police(); // some_operation failed
else if(war) // some_operation complains
{
std::cerr << "hold breath...";
if( war == some_error_condition )
thats_unacceptable();
//else ignore
}
Тем не менее, обратите внимание, что существуют реальные варианты использования, отклоняющиеся от моих рассуждений выше; действительно, такие вещи, как коды результатов HTTP и библиотеки (например, Vulkan) используют ненулевые «коды результатов» для успешных или частично успешных условий …
более того, Вот один из авторов диагностической библиотеки утверждает, что «Средство использует соглашение, где ноль означает успех». и в то же время использует error_code моделировать ошибки HTTP (200код состояния включен).
Это порождает некоторые сомнения относительно фактической семантики error_code::operator bool() (значение которого явно не изложено в стандарте) или об эффективной способности стандартной диагностической библиотеки моделировать концепцию кода ошибки в общем виде. YMMV.
Другие решения
Есть несколько вариантов для библиотеки, чтобы сообщить пользователю, что что-то пошло не так или не соответствует ожидаемому вызову функции.
- исключения. Но есть исключение накладных расходов, попробуйте / поймайте …
- повышение / станд :: необязательный. Если произошла ошибка / предупреждение, вы можете выдать его как возвращаемое значение (входной / выходной или выходной параметр), в противном случае необязательный параметр будет иметь значение false
- станд :: пара / станд :: кортеж. Таким образом, вы можете кодировать больше информации в возвращаемом значении (хотя пользовательская структура также может делать это более явно)
Вы можете ввести свою собственную структуру данных об ошибках (не используйте std::error_code как это зависит от ОС).
Убивать приложение из библиотеки тоже не очень удобно. Даже если это неустранимая ошибка в библиотеке, она не должна сильно влиять на фактическое вызывающее приложение / процесс / что угодно. Пусть звонящий решит, что делать.
Но все это вообще не применимо. Не существует универсального решения для обработки ошибок. Это может быть очень точно, где / как / когда используется ваша библиотека, поэтому вы хотите проверить, что соответствует вашей цели и насколько сильными должны быть / должны быть ограничения вызова.
Во всех случаях будьте ясны в отношении того, что может ожидать вызывающая сторона от вашей обработки ошибок, и не создавайте ощущения ракетостроения. Минимальный дизайн очень полезен здесь Imo.