Вы (Действительно) пишете исключению безопасный код? [закрытый]

В вашем вопросе содержится утверждение, что «писать код, безопасный для исключений, очень сложно». Сначала я отвечу на ваши вопросы, а затем отвечу на скрытый за ними вопрос.

Ответы на вопросы

Вы действительно пишете код, безопасный для исключений?

Конечно, пишу.

Это причина того, что Java потеряла свою привлекательность для меня как программиста на C ++ (отсутствие семантики RAII), но я отвлекся: это вопрос C ++.

На самом деле это необходимо, когда вам нужно работать с кодом STL или Boost. Например, потоки C ++ ( boost :: thread или std :: thread ) вызовут исключение для корректного завершения.

Вы уверены, что ваш последний "готовый к производству" код - в порядке исключения?

Можете ли вы быть уверены, что это такое?

Написание кода, безопасного для исключений, похоже на написание кода без ошибок.

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

Знаете ли вы и / или действительно используете альтернативы, которые работают?

Есть нет жизнеспособные альтернативы в C ++ (т.е. вам нужно будет вернуться к C и избегать библиотек C ++, а также внешних сюрпризов, таких как Windows SEH).

Написание кода, безопасного для исключений

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

Например, new может вызвать исключение, но присвоение встроенного (например, int или указателя) ) не подведет. Своп никогда не завершится ошибкой (никогда не пишите бросающий своп), a std :: list: : push_back может выбросить ...

Гарантия исключения

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

1. none : Ваш код никогда не должен предлагать этого. Этот код приведет к утечке всего и выйдет из строя при самом первом сгенерированном исключении.
2. basic : Это гарантия, которую вы должны как минимум предложить, то есть, если возникает исключение, утечки ресурсов не происходит, и все объекты по-прежнему целы
3. сильный : обработка либо завершится успешно, либо вызовет исключение, но если она выдаст, то данные будут в том же состоянии, как если бы обработка вообще не началась (это дает возможность транзакций для C ++)
4. nothrow / nofail : Обработка завершится успешно.

Пример кода

Следующий код выглядит как правильный C ++, но на самом деле предлагает гарантию «нет», и, следовательно, это неверно:

void doSomething(T & t)
{
   if(std::numeric_limits<int>::max() > t.integer)  // 1.   nothrow/nofail
      t.integer += 1 ;                              // 1'.  nothrow/nofail
   X * x = new X() ;                // 2. basic : can throw with new and X constructor
   t.list.push_back(x) ;            // 3. strong : can throw
   x->doSomethingThatCanThrow() ;   // 4. basic : can throw
}

Я пишу весь свой код с учетом такого рода анализа.

Самая низкая из предлагаемых гарантий является базовой, но затем порядок каждой инструкции делает всю функцию «none», потому что если 3. throws, x будет протекать.

Первое, что нужно сделать, это сделать функцию «базовой», то есть поместить x в умный указатель, пока он не станет безопасно принадлежать списку:

void doSomething(T & t)
{
   if(std::numeric_limits<int>::max() > t.integer)  // 1.   nothrow/nofail
      t.integer += 1 ;                              // 1'.  nothrow/nofail
   std::auto_ptr<X> x(new X()) ;    // 2.  basic : can throw with new and X constructor
   X * px = x.get() ;               // 2'. nothrow/nofail
   t.list.push_back(px) ;           // 3.  strong : can throw
   x.release() ;                    // 3'. nothrow/nofail
   px->doSomethingThatCanThrow() ;  // 4.  basic : can throw
}

Теперь наш код предлагает «базовую» гарантию. Ничего не протечет, и все объекты будут в исправном состоянии. Но мы могли бы предложить больше, то есть сильную гарантию. Именно здесь может стать дорогостоящим, и поэтому не весь код C ++ является сильным. Попробуем:

void doSomething(T & t)
{
   // we create "x"
   std::auto_ptr<X> x(new X()) ;    // 1. basic : can throw with new and X constructor
   X * px = x.get() ;               // 2. nothrow/nofail
   px->doSomethingThatCanThrow() ;  // 3. basic : can throw

   // we copy the original container to avoid changing it
   T t2(t) ;                        // 4. strong : can throw with T copy-constructor

   // we put "x" in the copied container
   t2.list.push_back(px) ;          // 5. strong : can throw
   x.release() ;                    // 6. nothrow/nofail
   if(std::numeric_limits<int>::max() > t2.integer)  // 7.   nothrow/nofail
      t2.integer += 1 ;                              // 7'.  nothrow/nofail

   // we swap both containers
   t.swap(t2) ;                     // 8. nothrow/nofail
}

Мы изменили порядок операций, сначала создайте и установите X на правильное значение. Если какая-либо операция завершается неудачно, то t не изменяется, поэтому операции с 1 по 3 могут считаться «сильными»: если что-то выдает, t не изменяется, а X не будет протекать, потому что он принадлежит интеллектуальному указателю.

Затем мы создаем копию t2 из t и работаем с этой копией с операций с 4 по 7. Если что-то бросает, t2 изменяется, но тогда t по-прежнему остается исходным. Мы по-прежнему предлагаем сильную гарантию.

Затем мы меняем местами t и t2 . Операции подкачки не должны выполняться в C ++, так что будем надеяться, что своп, который вы написали для T , не является свопом (если это не так, перепишите его так, чтобы он не вытеснялся).

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

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

Заключение

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

Конечно, компилятор C ++ не будет выполнять резервное копирование гарантия (в моем коде, Я предлагаю гарантию в виде тега @warning doxygen), что отчасти печально, но оно не должно останавливать вас от попыток написать безопасный для исключений код.

Нормальный сбой или ошибка.

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

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

Исключения относятся к исключительной ошибке обработки, а не к ошибкам кода.

Последние слова

Теперь вопрос: «Стоит ли это того?».

Of конечно, это так. Иметь "

• [я] Своп никогда не потерпит неудачу (даже не пишите бросающий своп)
• [nobar] Это хорошая рекомендация для специально написанных функций swap () . Однако следует отметить, что std :: swap () может завершиться ошибкой в ​​зависимости от операций, которые он использует внутри

, значение по умолчанию std :: swap будет делать копии и назначения , который для некоторых объектов может бросать. Таким образом, своп по умолчанию может быть использован либо для ваших классов, либо даже для классов STL. Что касается стандарта C ++, операция подкачки для vector , deque и list не будет вызывать, тогда как для map , если функтор сравнения может вызывать копирование (см. Язык программирования C ++, специальный выпуск, приложение E, E.4.3.Swap ).

Рассмотрение реализации вектора в Visual C ++ 2008 поменять местами, своп векторов не сработает, если два вектора имеют один и тот же распределитель (т. е. в нормальном случае), но будут делать копии, если у них разные распределители. И поэтому я предполагаю, что в последнем случае он мог бы бросить.

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

Edit 2011-11-06: Интересная статья

Дэйв Абрахамс , который дал нам базовые / сильные / ненадежные гарантии , описал в статье свой опыт о обеспечение безопасности исключений STL:

http://www.boost.org/community/exception_safety.html

Взгляните на 7-й пункт (Автоматическое тестирование на безопасность исключений), где он полагается на автоматическое модульное тестирование, чтобы сделать уверен, что каждый случай проверен. Думаю, эта часть является отличным ответом на вопрос автора « Можете ли вы быть уверены, что это так? ».

Редактировать 2013-05-31: Комментарий от dionadar

t.integer + = 1; не дает гарантии того, что переполнение не произойдет, НЕ безопасно для исключений и фактически может технически вызвать UB! (Переполнение со знаком - UB: C ++ 11 5/4 «Если во время вычисления выражения результат математически не определен или не находится в диапазоне представимых значений для его типа, поведение не определено».) Обратите внимание, что без знака integer не переполняются, но выполняют свои вычисления в классе эквивалентности по модулю 2 ^ # битов.

Dionadar имеет в виду следующую строку, которая действительно имеет неопределенное поведение.

   t.integer += 1 ;                 // 1. nothrow/nofail

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

Я исправил код с учетом комментария Дионадара.