Catch runtime error c

Типы исключений

Последнее обновление: 05.10.2017

Кроме типа exception в C++ есть еще несколько производных типов исключений, которые могут использоваться при различных ситуациях. Основные из них:

• runtime_error: общий тип исключений, которые возникают во время выполнения

• range_error: исключение, которое возникает, когда полученный результат превосходит допустимый диапазон

• overflow_error: исключение, которое возникает, если полученный результат превышает допустимый диапазон

• underflow_error: исключение, которое возникает, если полученный в вычислениях результат имеет недопустимые отрицательное значение (выход за нижнюю допустимую границу значений)

• logic_error: исключение, которое возникает при наличии логических ошбок к коде программы

• domain_error: исключение, которое возникает, если для некоторого значения, передаваемого в функцию, не определено результата

• invalid_argument: исключение, которое возникает при передаче в функцию некорректного аргумента

• length_error: исключение, которое возникает при попытке создать объект большего размера, чем допустим для данного типа

• out_of_range: исключение, которое возникает при попытке доступа к элементам вне допустимого диапазона

Большинство этих типов определено в заголовочном файле stdexcept, за исключением класса bad_alloc,
который определн в файле new, и класса bad_cast, который определен в файле
type_info.

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

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

При использовании нескольких блоков catch вначале помещаются блоки catch, которые обрабатывают более частные исключения, а только потом блоки catch с более
общими типами исключений:

#include <iostream>
#include <exception>
#include <stdexcept>

double divide(int, int);

int main()
{
	int x = 500;
	int y = 0;
	try
	{
		double z = divide(x, y);
		std::cout << z << std::endl;
	}
	catch (std::overflow_error err)
	{
		std::cout << "Overflow_error: " << err.what() << std::endl;
	}
	catch (std::runtime_error err)
	{
		std::cout << "Runtime_error: " << err.what() << std::endl;
	}
	catch (std::exception err)
	{
		std::cout << "Exception!!!"<< std::endl;
	}
	std::cout << "The End..." << std::endl;
	return 0;
}

double divide(int a, int b)
{
	if (b == 0)
		throw std::runtime_error("Division by zero!");
	return a / b;
}

Здесь функция divide, если параметр b равен 0, выбрасывает исключение типа runtime_error. Исключение инициализируется
сообщением об ошибке «Division by zero!».

В функции main конструкция try..catch использует три блока catch. Причем последний блок представляет самый общий тип исключений exception. Второй блок
обрабатывает исключения типа runtime_error, производный от exception. А первый блок обрабатывает исключения типа overflow_error, который является производным от
runtime_error.

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

Runtime_error: Division by zero!
The End...

Что такое исключение? Это ситуация, которая не предусмотрена стандартным поведением программы. Например, попытка доступа к элементу в классе Vector (который мы разбирали в статье про

классы

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

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

Для разрешения таких ситуация в C++ можно использовать технику исключений.

Рассмотрим, как написать вызов исключения в случае попытки доступа к элементу по индексу, который не существует в классе Vector.

double& Vector::operator[](int i)
{
    if (i<0 || size()<=i) throw out_of_range{"Vector::operator[]"};
    return elem[i];
}


  Здесь применяется исключение

  

   out_of_range.

  

  Данное исключение определено в заголовочном файле

  

    .

   



  


                       
  





  Оператор

  

   throw

  

  передаёт контроль обработчику для исключений типа

  

   out_of_range

  

  в некоторой функции, которая прямо или косвенно вызывает

  

   Vector::operator

   

  . Для того, чтобы обработать исключения необходимо воспользоваться блоком операторов

  

   try catch.

  
void f(Vector& v)
{
    // ...
    try { // блок обработки функции с исключением
        v[v.size()] = 7; // попытка доступа к элементу за пределами вектора
    }
    catch (out_of_range) { // ловим ошибку out_of_range 
        // ... обработки ошибки out_of_range ...
    }
    // ...
}


  Инварианты

 

  Также блоки

  

   try catch

  

  позволяют производить обработку нескольких различных исключений, что вносит инвариантность в работу механизма исключений C++.
 

  Например, класс вектор при создании может получить неправильный размер вектора или не найти свободную память для элементов, которые он будет содержать.
 
Vector::Vector(int s)
{
    if (s < 0) throw length_error{};
    elem = new double[s];
    sz = s;
}


  Данный конструктор может выбросить исключение в двух случаях:
 


   Если в качестве аргумента

   

    size

   

   будет передано отрицательное значение
  

   Если оператор

   

    new

   

   не сможет выделить память
  



   length_error

  

  — это стандартный оператор исключений, поскольку библиотека std часто использует данные исключения при своей работе.
 

  Обработка исключений будет выглядеть следующим образом:
 
void test()
{
    try {
        Vector v(−27);
    }
    catch (std::length_error) {
        // обработка отрицательного размера вектора
    }
    catch (std::bad_alloc) {
        // обработка ошибки выделения памяти
    }
}


  Также можно выделить свои собственные исключения.
 

  Виды исключений

 

  Все исключения стандартной библиотеки наследуются от

  

   std::exception.

  

  На данный момент существуют следующие виды исключений:
 


   logic_error
  

   invalid_argument
  

   domain_error
  

   length_error
  

   out_of_range
  

   future_error (C++11)
  

   runtime_error
  

   range_error
  

   overflow_error
  

   underflow_error
  

   system_error (C++11)
  

   ios_base::failure (начиная с C++11)
  

   bad_typeid
  

   bad_cast
  

   bad_weak_ptr (C++11)
  

   bad_function_call (C++11)
  

   bad_alloc
  

   bad_array_new_length (C++11)
  

   bad_exception
  

   ios_base::failure (до C++11)
  


  std::logic_error

 

  Исключение определено в заголовочном файле
  



  


                       
  





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

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

  std::invalid_argument

 

  Исключение определено в заголовочном файле
  

  Наследован от std::logic_error. Определяет исключение, которое должно быть брошено в случае неправильного аргумента.
 

  Например, на MSDN приведён пример, когда в объект класса bitset из стандартной библиотеки
 
// invalid_arg.cpp  
// compile with: /EHsc /GR  
#include <bitset>  
#include <iostream>  

using namespace std;  

int main( )  
{  
   try   
   {  
      bitset< 32 > bitset( string( "11001010101100001b100101010110000") );  
   }  
   catch ( exception &e )   
   {  
      cerr << "Caught " << e.what( ) << endl;  
      cerr << "Type " << typeid( e ).name( ) << endl;  
   };  
}  
* Output:   
Caught invalid bitset<N> char  
Type class std::invalid_argument  
* 


  В данном примере передаётся неправильная строка, внутри которой имеется символ ‘b’, который будет ошибочным.
 

  std::domain_error

 

  Исключение определено в заголовочном файле
  

  Наследован от std::logic_error. Определяет исключение, которое должно быть брошено в случае если математическая функция не определена для того аргумента, который ей передаётся, например:
 
std::sqrt(-1)


  std::length_error

 

  Исключение определено в заголовочном файле
  

  Наследован от std::logic_error. Определяет исключение, которое должно быть броше в том случае, когда осуществляется попытка реализации превышения допустим пределов для объекта. Как это было показано для размера вектора в начале статьи.
 



  


                       
  





  std::out_of_range

 

  Исключение определено в заголовочном файле
  

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

  std::future_error

 

  Исключение определено в заголовочном файле
  

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

  

   std::error_code

  

  .
 

  std::runtime_error

 

  Исключение определено в заголовочном файле
  

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

  std::range_error

 

  Исключение определено в заголовочном файле
  

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

  

   underflow_error

  

  или

  

   overflow_error

  

  .
 

  std::overflow_error

 

  Исключение определено в заголовочном файле
  

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



  


                       
  





  std::underflow_error

 

  Исключение определено в заголовочном файле
  

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

  std::system_error

 

  Исключение определено в заголовочном файле
  


   std::system_error

  

  — это тип исключения, которое вызывается различными функциями стандартной библиотеки (как правило, функции, которые взаимодействуют с операционной системой, например, конструктор

  

   std::thread

  

  ), при этом исключение имеет соответствующий

  

   std::error_code

  

  .
 

  std::ios_base::failure

 

  Исключение определено в заголовочном файле
  

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

  std::bad_typeid

 

  Исключение определено в заголовочном файле
  

  Исключение этого типа возникает, когда оператор

  

   typeid

  

  применяется к нулевому указателю полиморфного типа.
 
#include <iostream>
#include <typeinfo>

struct S { // Тип должен быть полиморфным
    virtual void f();
}; 

int main()
{
    S* p = nullptr;
    try {
        std::cout << typeid(*p).name() << 'n';
    } catch(const std::bad_typeid& e) {
        std::cout << e.what() << 'n';
    }
}


  std::bad_cast

 

  Исключение определено в заголовочном файле
  

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



  


                       
  




#include <iostream>
#include <typeinfo>

struct Foo { virtual ~Foo() {} };
struct Bar { virtual ~Bar() {} };

int main()
{
    Bar b;
    try {
        Foo& f = dynamic_cast<Foo&>(b);
    } catch(const std::bad_cast& e)
    {
        std::cout << e.what() << 'n';
    }
}


  std::bad_weak_ptr

 

  Исключение определено в заголовочном файле
  


   std::bad_weak_ptr

  

  – тип объекта, генерируемый в качестве исключения конструкторами

  

   std::shared_ptr

  

  , которые принимают

  

   std::weak_ptr

  

  в качестве аргумента, когда

  

   std::weak_ptr

  

  ссылается на уже удаленный объект.
 
#include <memory>
#include <iostream>
int main()
{
    std::shared_ptr<int> p1(new int(42));
    std::weak_ptr<int> wp(p1);
    p1.reset();
    try {
        std::shared_ptr<int> p2(wp);
    } catch(const std::bad_weak_ptr& e) {
        std::cout << e.what() << 'n';
    }
}


  std::bad_function_call

 

  Исключение определено в заголовочном файле
  

  Данное исключение генерируется в том случае, если был вызван метод

  

   std::function::operator()

  

  объекта

  

   std::function

  

  , который не получил объекта функции, то есть ему был передан в качестве инициализатора nullptr, например, а объект функции так и не был передан.
 
#include <iostream>
#include <functional>

int main()
{
    std::function<int()> f = nullptr;
    try {
        f();
    } catch(const std::bad_function_call& e) {
        std::cout << e.what() << 'n';
    }
}


  std::bad_alloc

 

  Исключение определено в заголовочном файле
  

  Вызывается в том случае, когда не удаётся выделить память.
 

  std::bad_array_new_length

 

  Исключение определено в заголовочном файле
  

  Исключение вызывается в следующих случаях:
 


   Массив имеет отрицательный размер
  

   Общий размер нового массива превысил максимальное значение, определяемое реализацией
  

   Количество элементов инициализации превышает предлагаемое количество инициализирующих элементов
  

#include <iostream>
#include <new>
#include <climits>

int main()
{
    int negative = -1;
    int small = 1;
    int large = INT_MAX;
    try {
        new int[negative];           // negative size
        new int[small]{1,2,3};       // too many initializers
        new int[large][1000000];     // too large
    } catch(const std::bad_array_new_length &e) {
        std::cout << e.what() << 'n';
    }
}


  std::bad_exception

 

  Исключение определено в заголовочном файле
  


   std::bad_exception

  

  — это тип исключения в C++, которое выполняется в следующих ситуациях:
 



  


                       
  






   Если нарушается динамическая спецификация исключений
  

   Если

   

    std::exception_ptr

   

   хранит копию пойманного исключения, и если конструктор копирования объекта исключения поймал current_exception, тогда генерируется исключение захваченных исключений.
  

#include <iostream>
#include <exception>
#include <stdexcept>

void my_unexp() { throw; }

void test() throw(std::bad_exception)
{
    throw std::runtime_error("test");
}

int main()
{
    std::set_unexpected(my_unexp);
    try {
         test();
    } catch(const std::bad_exception& e)
    {
        std::cerr << "Caught " << e.what() << 'n';
    }
}

Associates one or more exception handlers (catch-clauses) with a compound statement.

[edit] Syntax

where handler-sequence is a sequence of one or more handlers, which have the following syntax:

try { /* */ } catch (...) { /* */ }

[edit] Explanation

See throw exceptions for more information about throw-expressions

A try-block is a statement, and as such, can appear anywhere a statement can appear (that is, as one of the statements in a compound statement, including the function body compound statement). See function-try-block for the try blocks around function bodies. The following description applies to both try-blocks and function-try-blocks.

The formal parameter of the catch clause (type-specifier-seq and declarator or type-specifier-seq and abstract-declarator) determines which types of exceptions cause this catch clause to be entered. It cannot be an incomplete type, abstract class type, rvalue reference type, (since C++11) or pointer to incomplete type (except that pointers to (possibly cv-qualified) void are allowed). If the type of the formal parameter is array type or function type, it is treated as the corresponding pointer type (similar to a function declaration).

When an exception is thrown by any statement in compound-statement, the exception object of type E is matched against the types of the formal parameters T of each catch-clause in handler-seq, in the order in which the catch clauses are listed. The exception is a match if any of the following is true:

• E and T are the same type (ignoring top-level cv-qualifiers on T)
• T is an lvalue-reference to (possibly cv-qualified) E
• T is an unambiguous public base class of E
• T is a reference to an unambiguous public base class of E
• T is (possibly cv-qualified) U or const U& (since C++14), and U is a pointer or pointer to member type, and E is also a pointer or pointer to member type that is implicitly convertible to U by one or more of

• a standard pointer conversion other than one to a private, protected, or ambiguous base class
• a qualification conversion

try
{
    f();
}
catch (const std::overflow_error& e)
{} // this executes if f() throws std::overflow_error (same type rule)
catch (const std::runtime_error& e)
{} // this executes if f() throws std::underflow_error (base class rule)
catch (const std::exception& e)
{} // this executes if f() throws std::logic_error (base class rule)
catch (...)
{} // this executes if f() throws std::string or int or any other unrelated type

The catch-all clause catch (…) matches exceptions of any type. If present, it has to be the last catch clause in the handler-seq. Catch-all block may be used to ensure that no uncaught exceptions can possibly escape from a function that offers nothrow exception guarantee.

If no matches are found after all catch-clauses were examined, the exception propagation continues to the containing try-block, as described in throw-expression. If there are no containing try-blocks left, std::terminate is executed (in this case, it is implementation-defined whether any stack unwinding occurs at all: throwing an uncaught exception is permitted to terminate the program without invoking any destructors).

When entering a catch clause, if its formal parameter is a base class of the exception type, it is copy-initialized from the base class subobject of the exception object. Otherwise, it is copy-initialized from the exception object (this copy is subject to copy elision).

try
{
    std::string("abc").substr(10); // throws std::length_error
}
// catch (std::exception e) // copy-initialization from the std::exception base
// {
//     std::cout << e.what(); // information from length_error is lost
// }
catch (const std::exception& e) // reference to the base of a polymorphic object
{
    std::cout << e.what(); // information from length_error printed
}

If the parameter of the catch-clause is a reference type, any changes made to it are reflected in the exception object, and can be observed by another handler if the exception is rethrown with throw;. If the parameter is not a reference, any changes made to it are local and its lifetime ends when the handler exits.

A goto or switch statement shall not be used to transfer control into a try block or into a handler.

Other than by throwing or rethrowing the exception, the catch-clause after a regular try block (not function-try-block) may be exited with a return, continue, break, goto, or by reaching the end of its compound-statement. In any case, this destroys the exception object (unless an instance of std::exception_ptr exists that refers to it).

[edit] Notes

The throw-expression throw NULL; is not guaranteed to be matched by a pointer catch clause, because the exception object type may be int, but throw nullptr; is assuredly matched by any pointer or pointer-to-member catch clause.

If a catch-clause for a derived class is placed after the catch-clause for a base class, the derived catch-clause will never be executed:

If goto is used to exit a try-block and if any of the destructors of block-scoped automatic variables that are executed by the goto throw exceptions, those exceptions are caught by the try blocks in which the variables are defined:

label:
    try
    {
        T1 t1;
        try
        {
            T2 t2;
            if (condition)
                goto label; // destroys t2, then destroys t1, then jumps to label
        }
        catch (...) {} // catches the exception from the destructor of t2
    }
    catch (...) {}     // catches the exception from the destructor of t1

[edit] Keywords

try,
catch,
throw

[edit] Example

#include <iostream>
#include <vector>
 
int main()
{
    try
    {
        std::cout << "Throwing an integer exception...n";
        throw 42;
    }
    catch (int i)
    {
        std::cout << " the integer exception was caught, with value: " << i << 'n';
    }
 
    try
    {
        std::cout << "Creating a vector of size 5... n";
        std::vector<int> v(5);
        std::cout << "Accessing the 11th element of the vector...n";
        std::cout << v.at(10); // vector::at() throws std::out_of_range
    }
    catch (const std::exception& e) // caught by reference to base
    {
        std::cout << " a standard exception was caught, with message '"
                  << e.what() << "'n";
    }
}

Throwing an integer exception...
 the integer exception was caught, with value: 42
Creating a vector of size 5...
Accessing the 11th element of the vector...
 a standard exception was caught, with message 'out_of_range'

[edit] Defect reports

The following behavior-changing defect reports were applied retroactively to previously published C++ standards.

One of the advantages of C++ over C is Exception Handling. Exceptions are runtime anomalies or abnormal conditions that a program encounters during its execution. There are two types of exceptions: a)Synchronous, b)Asynchronous (i.e., exceptions which are beyond the program’s control, such as disc failure, keyboard interrupts etc.). C++ provides the following specialized keywords for this purpose:
try: Represents a block of code that can throw an exception.
catch: Represents a block of code that is executed when a particular exception is thrown.
throw: Used to throw an exception. Also used to list the exceptions that a function throws but doesn’t handle itself.

Why Exception Handling? 
The following are the main advantages of exception handling over traditional error handling:

1) Separation of Error Handling code from Normal Code: In traditional error handling codes, there are always if-else conditions to handle errors. These conditions and the code to handle errors get mixed up with the normal flow. This makes the code less readable and maintainable. With try/catch blocks, the code for error handling becomes separate from the normal flow.

2) Functions/Methods can handle only the exceptions they choose: A function can throw many exceptions, but may choose to handle some of them. The other exceptions, which are thrown but not caught, can be handled by the caller. If the caller chooses not to catch them, then the exceptions are handled by the caller of the caller. 
In C++, a function can specify the exceptions that it throws using the throw keyword. The caller of this function must handle the exception in some way (either by specifying it again or catching it).

3) Grouping of Error Types: In C++, both basic types and objects can be thrown as exceptions. We can create a hierarchy of exception objects, group exceptions in namespaces or classes and categorize them according to their types.
 

C++ Exceptions:

When executing C++ code, different errors can occur: coding errors made by the programmer, errors due to wrong input, or other unforeseeable things.

When an error occurs, C++ will normally stop and generate an error message. The technical term for this is: C++ will throw an exception (error).

C++ try and catch:

Exception handling in C++ consists of three keywords: try, throw and catch:

The try statement allows you to define a block of code to be tested for errors while it is being executed.

The throw keyword throws an exception when a problem is detected, which lets us create a custom error.

The catch statement allows you to define a block of code to be executed if an error occurs in the try block.

The try and catch keywords come in pairs:

We use the try block to test some code: If the value of a variable “age” is less than 18, we will throw an exception, and handle it in our catch block.

In the catch block, we catch the error if it occurs and do something about it. The catch statement takes a single parameter. So, if the value of age is 15 and that’s why we are throwing an exception of type int in the try block (age), we can pass “int myNum” as the parameter to the catch statement, where the variable “myNum” is used to output the value of age.

If no error occurs (e.g. if age is 20 instead of 15, meaning it will be greater than 18), the catch block is skipped.

Exception Handling in C++

1) The following is a simple example to show exception handling in C++. The output of the program explains the flow of execution of try/catch blocks. 

Output: 

Before try
Inside try
Exception Caught
After catch (Will be executed)

2) There is a special catch block called the ‘catch all’ block, written as catch(…), that can be used to catch all types of exceptions. For example, in the following program, an int is thrown as an exception, but there is no catch block for int, so the catch(…) block will be executed. 

Output: 

Default Exception

3) Implicit type conversion doesn’t happen for primitive types. For example, in the following program, ‘a’ is not implicitly converted to int. 

Output: 

Default Exception

4) If an exception is thrown and not caught anywhere, the program terminates abnormally. For example, in the following program, a char is thrown, but there is no catch block to catch the char.  

Output: 

terminate called after throwing an instance of 'char'

This application has requested the Runtime to terminate it in an 
unusual way. Please contact the application's support team for 
more information.

We can change this abnormal termination behavior by writing our own unexpected function.
5) A derived class exception should be caught before a base class exception. See this for more details.
6) Like Java, the C++ library has a standard exception class which is the base class for all standard exceptions. All objects thrown by the components of the standard library are derived from this class. Therefore, all standard exceptions can be caught by catching this type
7) Unlike Java, in C++, all exceptions are unchecked, i.e., the compiler doesn’t check whether an exception is caught or not (See this for details). So, it is not necessary to specify all uncaught exceptions in a function declaration. Although it’s a recommended practice to do so. For example, the following program compiles fine, but ideally the signature of fun() should list the unchecked exceptions. 

Output: 

Caught exception from fun()

A better way to write the above code: 

Note : The use of Dynamic Exception Specification has been deprecated since C++11. One of the reasons for it may be that it can randomly abort your program. This can happen when you throw an exception of another type which is not mentioned in the dynamic exception specification. Your program will abort itself because in that scenario, it calls (indirectly) terminate(), which by default calls abort().

Output: 

Caught exception from fun()

In C++, try/catch blocks can be nested. Also, an exception can be re-thrown using “throw; “. 

Output: 

Handle Partially Handle remaining

A function can also re-throw a function using the same “throw; ” syntax. A function can handle a part and ask the caller to handle the remaining.
9) When an exception is thrown, all objects created inside the enclosing try block are destroyed before the control is transferred to the catch block.

Output: 

Constructor of Test
Destructor of Test
Caught 10

10) You may like to try Quiz on Exception Handling in C++.
Please write comments if you find anything incorrect, or you want to share more information about the topic discussed above.
 

В интернете довольно много говорят о новых возможностях C++11: auto, lambda, variadic templates. Но как-то обошли стороной новые возможности работы с исключениями, которые предоставляет язык и стандартная библиотека.

От предыдущей версии стандарта остался механизм генерации исключений (throw), проверка того, что мы находимся в процессе обработки исключения (std::uncaught_exception), механизм остановки, если исключение не было обработано. Также есть иерархия стандартных исключений на базе класса std::exception.

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

exception_ptr

Итак, самое первое, с чем мы можем столкнуться — это std::exception_ptr. Этот тип позволяет в себе хранить исключение абсолютно любого типа. Стандарт не оговаривает каким образом получен этот тип. Это может быть typedef, это может быть реализация класса. Его поведение сходно поведению std::shared_ptr, то есть его можно копировать, передавать в качестве параметра, при этом само исключение не копируется. Основное предназначение exception_ptr — это передача исключений в качестве параметров функции, возможна передача исключений между потоками. Таким образом, объекты данного типа позволяют сделать обработку ошибок более гибкой:

struct some_exception {
	explicit some_exception(int x): v(x) {
		std::cout << " int ctor" << std::endl;
	}

	some_exception(const some_exception & e): v(e.v) {
		std::cout << " copy ctor" << std::endl;
	}

	int v;
};

std::exception_ptr throwExceptionAndCaptureExceptionPtr() {
	std::exception_ptr currentException;
	try {
		const int throwValue = 10;
		std::cout << "throwing           " << throwValue << "..." << std::endl;
		throw some_exception(throwValue);

	} catch (...) {
		 currentException = std::current_exception();
	}

	return currentException;
}

void rethrowException(std::exception_ptr ePtr) {
	try {
		if (ePtr) {
			std::rethrow_exception(ePtr);
		}

	} catch (const some_exception & e) {
		std::cout << "catched int value: " << e.v << std::endl;
	}

	std::exception_ptr anotherExceptionPtr = ePtr;
	try {
		if (anotherExceptionPtr) {
			std::rethrow_exception(anotherExceptionPtr);
		}

	} catch (const some_exception & e) {
		std::cout << "catched int value: " << e.v << std::endl;
	}
}

void checkMakeExceptionPtr() {
	std::exception_ptr currentException = std::make_exception_ptr(some_exception(20));
	std::cout << "exception_ptr constructed" << std::endl;

	rethrowException(currentException);
}

void exceptionPtrSample() {
	rethrowException(throwExceptionAndCaptureExceptionPtr());
	checkMakeExceptionPtr();
}

Если мы запустим функцию exceptionPtrSample на выполнение, то увидим примерно следующий результат:

throwing 10…
int ctor
catched int value: 10
catched int value: 10
int ctor
copy ctor
copy ctor
exception_ptr constructed
catched int value: 20
catched int value: 20

Для того чтобы можно было удобно работать с exception_ptr, есть несколько вспомогательных функций:

• current_exception — данная функция возвращает exception_ptr. Если мы находимся внутри блока catch, то возвращает exception_ptr, который содержит обрабатываемое в данный момент текущим потоком исключение, если вызывать ее вне блока catch, то она вернет пустой объект exception_ptr
• rethrow_exception — данная функция бросает исключение, которое содержится в exception_ptr. Если входной параметр не содержит исключения (пустой объект), то результат не определен. При этом msvc кидает std::bad_exception, а программа собранная с помощью gcc-4.7.2 неожиданно завершается.
• make_exception_ptr — данная функция, может сконструировать exception_ptr без бросания исключения. Ее предназначение аналогично функции std::make_shared — конструирование объекта. Ее выполнение аналогично функции throwExceptionAndCaptureExceptionPtr. В реализации от gcc-4.7.2 make_exception_ptr делает два копирования объекта some_exception.

Передача исключений между потоками

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

void worker(std::promise<void> & p) {
	try {
		throw std::runtime_error("exception from thread");
	} catch (...) {
		p.set_exception(std::current_exception());
	}
}

void checkThreadAndException() {
	std::promise<void> p;
	auto result = p.get_future();

	std::thread t(worker, ref(p));
	t.detach();

	try {
		result.get();
	} catch (const std::runtime_error & e) {
		std::cout << "runtime error catched from async worker" << std::endl;
	}
}

Вообще, многопоточность в C++11 — это обширная тема, там есть свои тонкости, нюансы и о них следует писать отдельно. Сейчас мы рассмотрим этот пример только ради передачи исключения. Запускаем функцию worker в отдельном потоке, и эта функция кидает исключение. Объект класса promise позволяет организовать связь между разными потоками, и атомарно передать значения из одного потока в другой (или исключение). В данном примере мы как раз пользуемся методом set_exception, который принимает exception_ptr в качестве параметра. Для того чтобы получить значение, мы создаем объект класса future — это наш result и вызываем метод get. Также необходимо у потока вызвать метод detach или join, так как при разрушении объекта t в деструкторе проверяется, чтобы joinable() == false, иначе вызывается std::terminate. Скорее всего, это связано с тем, чтобы программист не «отпускал потоки на волю», а всегда следил за ними (либо отпускал явно с помощью метода detach)

Отдельно стоит сказать об использовании многопоточности в gcc-4.7. Изначально этот пример у меня не работал (выбрасывал исключение), погуглив, я выяснил, что для использования std::thread необходимо передать линкеру флаг -pthread. Так как я использую CMake в качестве системы сборки, то эта задача упрощается (тут сложность может возникнуть при использовании gcc на разных платформах, например на sparc solaris используется флаг -thread вместо -pthread) — есть специальный CMake модуль Threads, в котором эта проблема решена:

find_package(Threads REQUIRED)
#…
target_link_libraries(cxx_exceptions ${CMAKE_THREAD_LIBS_INIT})

Nested exceptions

Как видно из названия, данный механизм позволяет «прицепить» к кидаемому исключению другие исключения (которые могли быть брошены раньше). Например, если у нас есть своя иерархия исключений, то мы можем ловить все «сторонние» исключения, прицеплять их к своим исключениям, а при обработке своих исключений мы можем выводить доп. информацию, которая к ним «прицеплена» (например, при отладке, мы можем печатать информацию о сторонних исключениях). Хороший пример использования nested exception приведен на cppreference.com, мой пример, отчасти пересекается с ним:

struct third_party_exception {
	explicit third_party_exception(int e) : code(e) {
	}

	int code;
};


void third_party_worker() {
	throw third_party_exception(100);
}

class our_exception : public std::runtime_error {
public:
	our_exception(const std::string & e) : std::runtime_error("our error: " + e) {
	}
};

void ourWorker() {
	try {
		third_party_worker();
	} catch (...) {
		throw_with_nested(our_exception("worker failed"));
	}
}

void exceptionHandler(const our_exception & e, bool catchNested) {
	std::cerr << "our exception catched: " << e.what();

	if (catchNested) {
		try {
			rethrow_if_nested(e);
		} catch (const third_party_exception & e) {
			std::cerr << ", low level reason is: " << e.code;
		}
	}

	std::cerr << std::endl;
}

void exceptionProcessing() {
	try {
		ourWorker();
	} catch (const our_exception & e) {
		exceptionHandler(e, false);
	}

	try {
		ourWorker();
	} catch (const our_exception & e) {
		exceptionHandler(e, true);
	}
}

Итак, у нас есть сторонняя функция, которая кидает исключение, мы можем написать адаптер, который ловит «сторонние» исключения, и из них делает «наше» исключение: в качестве «сторонней» функции и «нашей» функции выступают соответственно third_party_worker и ourWorker. Мы ловим все исключения, и бросаем далее уже наше (our_exception) исключение, при этом, к нему было прицеплено какое-то (мы в принципе можем и не знать какое) «стороннее» исключение. После этого работаем уже с нашими исключениями. При этом, если нам понадобится более детальная информация о том, что происходило на «нижнем» уровне, то мы всегда можем вызвать функцию rethrow_if_nested. Данная функция анализирует, если ли прицепленное (вложенное) исключение, и если есть, то бросает это вложенное исключение. Функция exceptionHandler принимает «наше» исключение и дополнительный флаг, который разрешает или запрещает вывод информации о стороннем исключении. Мы можем управлять выводом сторонних исключений, управляя параметром catchNested, например, из файла конфигурации (или в зависимости от сборки — Release, Debug).

Для работы с nested exception есть один класс и две функции:

• nested_exception — данный класс «подмешивается» к бросаемому объекту при вызове функции std::throw_with_nested — этот класс также позволяет вернуть вложенное исключение (exception_ptr) с помощью метода nested_ptr. Также этот класс имеет метод rethrow_nested, который бросает вложенное исключение
• throw_with_nested — данная шаблонная функция принимает объект некоторого типа (назовем его InputType), и бросает объект который является наследником std::nested_exception и нашего InputType (в реализации от gcc — это шаблонный тип, который наследуется от nested_exception и InputType). Таким образом, мы можем ловить как объект нашего типа, так и объект типа nested_exception и уже потом получать наш тип через метод nested_ptr
• rethrow_if_nested — данная функция определяет, есть ли у объекта вложенное исключение, и если есть, то бросает его. Реализация может использовать dynamic_cast для определения наследования

В принципе, механизм nested exception довольно интересный, хотя реализация может быть довольно тривиальна, ее можно сделать самому, с помощью ранее описанных функций current_exception и rethrow_exception. В той же реализации gcc, класс nested_exception содержит одно поле типа exception_ptr, которое инициализируется в конструкторе с помощью функции current_exception, а реализация метода rethrow_nested просто вызывает функцию rethrow_exception.

Спецификация noexcept

Данный механизм можно рассматривать как расширенный (и ныне устаревший) механизм throw(). Основное его предназначение как и раньше — гарантия того что, функция не бросит исключение (если гарантия нарушается, то вызывается std::terminate).

Используется этот механизм в двух видах, аналогично старому throw()

void func() noexcept {
//...
}

И в новом виде:

void func() noexcept(boolean_expression_known_at_compile_time) {
//...
}

При этом, если значение выражения вычислено как истина, то функция помечается как noexcept, иначе, такой гарантии нет.
Также есть соответствующий оператор noexcept(expression), который тоже выполняется в compile time, этот оператор возвращает истину, если выражение не бросает исключение:

void noexceptSample() {
	cout << "noexcept int():         " << noexcept(int()) << endl;
	cout << "noexcept vector<int>(): " << noexcept(vector<int>()) << endl;
}

Данный код для gcc-4.7.2 выводит:

noexcept int(): 1
noexcept vector<int>(): 0

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

template <typename InputTypeT>
void func() noexcept(noexcept(InputTypeT())) {
	InputTypeT var;
	/// do smth with var
	std::cout << "func called, object size: " << sizeof(var) << std::endl;
}

void noexceptSample() {
	std::cout << "noexcept int():         " << noexcept(int()) << std::endl;
	std::cout << "noexcept vector<int>(): " << noexcept(std::vector<int>()) << std::endl << std::endl;

	/// @note function is not actually called
	std::cout << "noexcept func<int>:         " << noexcept(func<int>()) << std::endl;
	std::cout << "noexcept func<vector<int>>: " << noexcept(func<std::vector<int>>()) << std::endl;
}

Данный пример выводит:

noexcept int(): 1
noexcept vector<int>(): 0

noexcept func<int>: 1
noexcept func<vector<int>>: 0

Резюме

Стандарт C++11 привнес много нового в обработку ошибок, конечно, ключевой особенностью здесь остается exception_ptr и возможность передачи произвольных исключений как обычные объекты (в функции, передавать исключения между потоками). Раньше, в каждом потоке приходилось писать развесистый try… catch для всех исключений, а этот функционал существенно минимизирует количество try… catch кода.

Также появилась возможность создавать вложенные исключения, в принципе в библиотеке boost есть механизм boost::exception, который позволяет прикреплять к объекту произвольные данные (например коды ошибок, свои сообщения и пр), но он решает другие задачи — передачу произвольных данных внутри исключения.

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

Как обычно, все примеры выложены на github

Update 1. Убрал из примеров using namespace std, теперь видно какие сущности относятся к стандартной библиотеке, а какие нет.

Introduction

.NET provides a structured way of handling the runtime errors. Business logic and error handling code is separate. The errors that occur during the execution of a program are called the runtime errors or the exceptions. Some of the examples of runtime erros are Division by Zero, Stack overflow, Invalid type casting, and File not found.

Object-Oriented way of error handling is,

1. Classes to handle different types of errors.
2. FileNotFoundException class to represent, if the file not found.
3. IOException class to represent, if the file is already open.
4. SecurityException class to represent, if the caller does not have permission to access the file.
5. Easy to program and extend

Runtime errors occur during the execution of a program. Some exceptions are given below,

• Division by 0 exception occurs, when the denominator is zero.
• Stack overflow exception occurs, when there is no memory available to allocate on stack.
• File not found exception can occur, when we try to access a file from a particular location, where it does not exit.

These exceptions abnormally terminate a program. To avoid this, C# provides an in-built feature that is called an exception handling mechanism.

Exception handling mechanism provides a way to respond to the run time errors in the program by transferring control to special code called handler. This feature allows a clean separation between error detection code or business logic and error handling code.

The exception handling mechanism in C# provides try and catch blocks to effectively handle it.

Let’s see how to handle an exception practically.

1. For this, create new C# console project, as shown below.

   

2. Let’s write a code for reading a text file for the specific path, as shown below.

• The file path is shown below.

  

• Now, let’s try to read this sample file, using C# code, as given below.
  1. using System;  
  2. using System.IO;  
  3. namespace ConsoleApplication1 {  
  4.     class Program {  
  5.         static void Main(string[] args) {  
  6.             StreamReader strmRdr = new StreamReader(@ «E:Exception Handlingsample.txt»);  
  7.             Console.WriteLine(strmRdr.ReadToEnd());   
  8.             strmRdr.Close();   
  9.             Console.ReadLine();  
  10.         }  
  11.     }  
  12. }  

  

1. Let’s implement one exception to this reading code. Let’s change the file name so that in the file path, we can make it not exist and change the code, as shown below, and see what happens.

   

   As you see here, you will be getting an Exception System.IO.FileNotFoundException.

1. Now, we will see how to handle this. Using try catch, rewrite the code, as shown below.
   1. try {  
   2.     StreamReader strmRdr = new StreamReader(@ «E:Exception Handlingsample1.txt»);  
   3.     Console.WriteLine(strmRdr.ReadToEnd());   
   4.     strmRdr.Close();   
   5.     Console.ReadLine();  
   6. } catch (Exception ex) {  
   7.     Console.WriteLine(ex.Message);  
   8. }   

   

   Here, we will get the exact exception and the application will not crash.

   It is not a good way because here, we are displaying all the error messages which sometimes the user can’t understand. The hackers may use this information hack.

   Thus, we need to hide all these things and we have to display an error message in a better way. Exception is actually a class, which is derived from System.Exception class. This class has several useful properties, which provide valuable information about the exception.

   There are two main methods in this exception.

   Message
   Gets message that describes the current exception.

   Stack Trace
   Provides the call stack to the line number in the method, where the exception occurred

1. For this exception, we can use FileNotFoundException in catch block, so whenever this exception gets this, catch block will execute , else it does not, as shown below.

   

   See above that whenever we get FileNotFoundException, we can give the user a defined messge. Let’s check if an exception is something else other than this, then it will happen.

   

   I have changed the directory name, which does not exist, so the new exception is there. Since I am handling only FileNotFound exception, we have to give DirectoryNot found exception; you have to show some message and block this error.

   

1. Now, we have to know how to handle these exceptions but it still has a problem; i.e., I am getting an error in the line.
   1. StreamReader strmRdr = new StreamReader(@«C:Exception Handlingsample1.txt»);  

   Whatever is there will not execute. After getting an error, it goes to catch block, then this stream reader is still open. We need to release this resource for which we have to write final block after catch blocks. Actually, it is a good practice to write final block after catch block, if we are using resources like stramreader conection open etc., as shown below. 

   1. using System;  
   2. using System.IO;  
   3. namespace ConsoleApplication1 {  
   4.     class Program {  
   5.         static void Main(string[] args) {  
   6.             StreamReader strmRdr = null;  
   7.             try {  
   8.                 strmRdr = new StreamReader(@ «C:Exception Handlingsample.txt»);  
   9.                 Console.WriteLine(strmRdr.ReadToEnd());   
   10.                 strmRdr.Close();   
   11.                 Console.ReadLine();  
   12.             } catch (FileNotFoundException fx) {  
   13.                 Console.WriteLine(«Please check your file Name»);  
   14.                 Console.ReadLine();  
   15.             } catch (DirectoryNotFoundException fx) {  
   16.                 Console.WriteLine(«Please give a path where file exactly locate»);  
   17.                 Console.ReadLine();  
   18.             } finally {  
   19.                 if (strmRdr != null) {  
   20.                     strmRdr.Close();  
   21.                 }  
   22.             }  
   23.         }  
   24.     }   

   The Finally block will execute every time, so make sure whatever code is there inside the finally block is perfect.

1. If you get an exception inside the finally block it looks like this.

   

As you can see the file path is correct, even though the finally block is executed. I got an error conversion failed exception. Thus, what to do in these situations?

We can handle this in higher levels, as shown below, by adding try catch for all these codes

Other .NET exception classes are given below.

• SystemException
• FornatException
• ArithmaticException
• CoreException
• ArgumentException
• OutOfMemoryException
• NullReferenceException
• InvalidOperationException
• FormatException
• ArrayTypeMismatchException
• NotSupportedException, etc.

Note

• Exception class is the base class for all the exceptions
• Any code that is written cannot be completely bug-free.
• It is the responsibility of the developer to see to it that there are minimum bugs in the code.

В C++ различают ошибки времени компиляции и ошибки времени выполнения. Ошибки первого типа обнаруживает компилятор до запуска программы. К ним относятся, например, синтаксические ошибки в коде. Ошибки второго типа проявляются при запуске программы. Примеры ошибок времени выполнения: ввод некорректных данных, некорректная работа с памятью, недостаток места на диске и т. д. Часто такие ошибки могут привести к неопределённому поведению программы.

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

Коды возврата и исключения

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

int ReadAge() {
    int age;
    std::cin >> age;
    if (age < 0 || age >= 128) {
        // Что вернуть в этом случае?
    }
    return age;
}

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

int main() {
    if (int age = ReadAge(); age == 0) {
        // Произошла ошибка
    } else {
        // Работаем с возрастом age
    }
}

Такая проверка неудобна. Более того, нет никакой гарантии, что в вызывающей функции программист вообще её напишет. Фактически мы тут выбрали некоторое значение функции (ноль), обозначающее ошибку. Это пример подхода к обработке ошибок через коды возврата. Другим примером такого подхода является хорошо знакомая нам функция main. Только она должна возвращать ноль при успешном завершении и что-либо ненулевое в случае ошибки.

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

#include <iostream>

struct WrongAgeException {
    int age;
};

int ReadAge() {
    int age;
    std::cin >> age;
    if (age < 0 || age >= 128) {
        throw WrongAgeException(age);
    }
    return age;
}

Здесь в случае ошибки оператор throw генерирует исключение, которое представлено временным объектом типа WrongAgeException. В этом объекте сохранён для контекста текущий неправильный возраст age. Функция досрочно завершает работу: у неё нет возможности обработать эту ошибку, и она должна сообщить о ней наружу. Поток управления возвращается в то место, откуда функция была вызвана. Там исключение может быть перехвачено и обработано.

Перехват исключения

Мы вызывали нашу функцию ReadAge из функции main. Обработать ошибку в месте вызова можно с помощью блока try/catch:

int main() {
    try {
        age = ReadAge();  // может сгенерировать исключение
        // Работаем с возрастом age
    } catch (const WrongAgeException& ex) {  // ловим объект исключения
        std::cerr << "Age is not correct: " << ex.age << "n";
        return 1;  // выходим из функции main с ненулевым кодом возврата
    }
    // ...
}

Мы знаем заранее, что функция ReadAge может сгенерировать исключение типа WrongAgeException. Поэтому мы оборачиваем вызов этой функции в блок try. Если происходит исключение, для него подбирается подходящий catch-обработчик. Таких обработчиков может быть несколько. Можно смотреть на них как на набор перегруженных функций от одного аргумента — объекта исключения. Выбирается первый подходящий по типу обработчик и выполняется его код. Если же ни один обработчик не подходит по типу, то исключение считается необработанным. В этом случае оно пробрасывается дальше по стеку — туда, откуда была вызвана текущая функция. А если обработчик не найдётся даже в функции main, то программа аварийно завершается.

Усложним немного наш пример, чтобы из функции ReadAge могли вылетать исключения разных типов. Сейчас мы проверяем только значение возраста, считая, что на вход поступило число. Но предположим, что поток ввода досрочно оборвался, или на входе была строка вместо числа. В таком случае конструкция std::cin >> age никак не изменит переменную age, а лишь возведёт специальный флаг ошибки в объекте std::cin. Наша переменная age останется непроинициализированной: в ней будет лежать неопределённый мусор. Можно было бы явно проверить этот флаг в объекте std::cin, но мы вместо этого включим режим генерации исключений при таких ошибках ввода:

int ReadAge() {
    std::cin.exceptions(std::istream::failbit);
    int age;
    std::cin >> age;
    if (age < 0 || age >= 128) {
        throw WrongAgeException(age);
    }
    return age;
}

Теперь ошибка чтения в операторе >> у потока ввода будет приводить к исключению типа std::istream::failure. Функция ReadAge его не обрабатывает. Поэтому такое исключение покинет пределы этой функции. Поймаем его в функции main:

int main() {
    try {
        age = ReadAge();  // может сгенерировать исключения разных типов
        // Работаем с возрастом age
    } catch (const WrongAgeException& ex) {
        std::cerr << "Age is not correct: " << ex.age << "n";
        return 1;
    } catch (const std::istream::failure& ex) {
        std::cerr << "Failed to read age: " << ex.what() << "n";
        return 1;
    } catch (...) {
        std::cerr << "Some other exceptionn";
        return 1;
    }
    // ...
}

При обработке мы воспользовались функцией ex.what у исключения типа std::istream::failure. Такие функции есть у всех исключений стандартной библиотеки: они возвращают текстовое описание ошибки.

Обратите внимание на третий catch с многоточием. Такой блок, если он присутствует, будет перехватывать любые исключения, не перехваченные ранее.

Исключения стандартной библиотеки

Функции и классы стандартной библиотеки в некоторых ситуациях генерируют исключения особых типов. Все такие типы выстроены в иерархию наследования от базового класса std::exception. Иерархия классов позволяет писать обработчик catch сразу на группу ошибок, которые представлены базовым классом: std::logic_error, std::runtime_error и т. д.

Вот несколько примеров:

1. Функция at у контейнеров std::array, std::vector и std::deque генерирует исключение std::out_of_range при некорректном индексе.

2. Аналогично, функция at у std::map, std::unordered_map и у соответствующих мультиконтейнеров генерирует исключение std::out_of_range при отсутствующем ключе.

3. Обращение к значению у пустого объекта std::optional приводит к исключению std::bad_optional_access.

4. Потоки ввода-вывода могут генерировать исключение std::ios_base::failure.

Исключения в конструкторах

В главе 3.1 мы написали класс Time. Этот класс должен был соблюдать инвариант на значение часов, минут и секунд: они должны были быть корректными. Если на вход конструктору класса Time передавались некорректные значения, мы приводили их к корректным, используя деление с остатком.

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

class Time {
private:
    int hours, minutes, seconds;

public:
    // Заведём класс для исключения и поместим его внутрь класса Time как в пространство имён
    class IncorrectTimeException {
    };

    Time::Time(int h, int m, int s) {
        if (s < 0 || s > 59 || m < 0 || m > 59 || h < 0 || h > 23) {
            throw IncorrectTimeException();
        }
        hours = h;
        minutes = m;
        seconds = s;
    }

    // ...
};

Генерировать исключения в конструкторах — совершенно нормальная практика. Однако не следует допускать, чтобы исключения покидали пределы деструкторов. Чтобы понять причины, посмотрим подробнее, что происходит при генерации исключения.

Свёртка стека

Вспомним класс Logger из предыдущей главы. Посмотрим, как он ведёт себя при возникновении исключения. Воспользуемся в этом примере стандартным базовым классом std::exception, чтобы не писать свой класс исключения.

#include <exception>
#include <iostream>

void f() {
    std::cout << "Welcome to f()!n";
    Logger x;
    // ...
    throw std::exception();  // в какой-то момент происходит исключение
}

int main() {
    try {
        Logger y;
        f();
    } catch (const std::exception&) {
        std::cout << "Something happened...n";
        return 1;
    }
}

Мы увидим такой вывод:

Logger(): 1
Welcome to f()!
Logger(): 2
~Logger(): 2
~Logger(): 1
Something happened...

Сначала создаётся объект y в блоке try. Затем мы входим в функцию f. В ней создаётся объект x. После этого происходит исключение. Мы должны досрочно покинуть функцию. В этот момент начинается свёртка стека (stack unwinding): вызываются деструкторы для всех созданных объектов в самой функции и в блоке try, как если бы они вышли из своей области видимости. Поэтому перед обработчиком исключения мы видим вызов деструктора объекта x, а затем — объекта y.

Аналогично, свёртка стека происходит и при генерации исключения в конструкторе. Напишем класс с полем Logger и сгенерируем нарочно исключение в его конструкторе:

#include <exception>
#include <iostream>

class C {
private:
    Logger x;

public:
    C() {
        std::cout << "C()n";
        Logger y;
        // ...
        throw std::exception();
    }

    ~C() {
        std::cout << "~C()n";
    }
};

int main() {
    try {
        C c;
    } catch (const std::exception&) {
        std::cout << "Something happened...n";
    }
}

Вывод программы:

Logger(): 1  // конструктор поля x
C()
Logger(): 2  // конструктор локальной переменной y
~Logger(): 2  // свёртка стека: деструктор y
~Logger(): 1  // свёртка стека: деструктор поля x
Something happened...

Заметим, что деструктор самого класса C не вызывается, так как объект в конструкторе не был создан.

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

Пример с динамической памятью

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

void f() {
    Logger* ptr = new Logger();  // конструируем объект класса Logger в динамической памяти
    // ...
    g();  // вызываем какую-то функцию
    // ...
    delete ptr;  // вызываем деструктор и очищаем динамическую память
}

На первый взгляд кажется, что в этом коде нет ничего опасного: delete вызывается в конце функции. Однако функция g может сгенерировать исключение. Мы не перехватываем его в нашей функции f. Механизм свёртки уберёт со стека лишь сам указатель ptr, который является автоматической переменной примитивного типа. Однако он ничего не сможет сделать с объектом в памяти, на которую ссылается этот указатель. В логе мы увидим только вызов конструктора класса Logger, но не увидим вызова деструктора. Нам придётся обработать исключение вручную:

void f() {
    Logger* ptr = new Logger();
    // ...
    try {
        g();
    } catch (...) {  // ловим любое исключение
        delete ptr;  // вручную удаляем объект
        throw;  // перекидываем объект исключения дальше
    }
    // ...
    delete ptr;

}

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

Согласитесь, этот код очень далёк от совершенства. При непосредственной работе с объектами в динамической памяти нам приходится оборачивать в try/catch любую конструкцию, из которой может вылететь исключение. Понятно, что такой код чреват ошибками. В главе 3.6 мы узнаем, как с точки зрения C++ следует работать с такими ресурсами, как память.

Гарантии безопасности исключений

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

Не вдаваясь в детали, давайте посмотрим, как могла бы выглядеть функция добавления элемента.

template <typename T>
class List {
private:
    struct Node {  // узел двусвязного списка
        T element;
        Node* prev = nullptr;  // предыдущий узел
        Node* next = nullptr;  // следующий узел
    };

    Node* first = nullptr;  // первый узел списка
    Node* last = nullptr;  // последний узел списка
    int elementsCount = 0;

public:
    // ...

    size_t Size() const {
        return elementsCount;
    }

    void PushBack(const T& elem) {
        ++elementsCount;

        // Конструируем в динамической памяти новой узел списка
        Node* node = new Node(elem, last, nullptr);

        // Связываем новый узел с остальными узлами
        if (last != nullptr) {
            last->next = node;
        } else {
            first = node;
        }
        last = node;
    }
};

Не будем здесь рассматривать другие функции класса — конструкторы, деструктор, оператор присваивания… Рассмотрим функцию PushBack. В ней могут произойти такие исключения:

1. Выражение new может сгенерировать исключение std::bad_alloc из-за нехватки памяти.

2. Конструктор копирования класса T может сгенерировать произвольное исключение. Этот конструктор вызывается при инициализации поля element создаваемого узла в конструкторе класса Node. В этом случае new ведёт себя как транзакция: выделенная перед этим динамическая память корректно вернётся системе.

Эти исключения не перехватываются в функции PushBack. Их может перехватить код, из которого PushBack вызывался:

#include <iostream>

class C;  // какой-то класс

int main() {
    List<C> data;
    C element;

    try {
        data.PushBack(element);
    } catch (...) {  // не получилось добавить элемент
        std::cout << data.Size() << "n";  // внезапно 1, а не 0
    }

    // работаем дальше с data
}

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

Всего выделяют четыре уровня гарантий безопасности исключений (exception safety guarantees):

1. Гарантия отсутствия сбоев. Функции с такими гарантиями вообще не выбрасывают исключений. Примерами могут служить правильно написанные деструктор и конструктор перемещения, а также константные функции вида Size.

2. Строгая гарантия безопасности. Исключение может возникнуть, но от этого объект нашего класса не поменяет состояние: количество элементов останется прежним, итераторы и ссылки не будут инвалидированы и т. д.

3. Базовая гарантия безопасности. При исключении состояние объекта может поменяться, но оно останется внутренне согласованным, то есть, инварианты будут соблюдаться.

4. Отсутсвие гарантий. Это довольно опасная категория: при возникновении исключений могут нарушаться инварианты.

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

Переместим в нашей функции PushBack изменение счётчика в конец:

    void PushBack(const T& elem) {
        Node* node = new Node(elem, last, nullptr);

        if (last != nullptr) {
            last->next = node;
        } else {
            first = node;
        }
        last = node;

        ++elementsCount;  // выполнится только если раньше не было исключений
    }

Теперь такая функция соответствует строгой гарантии безопасности.

В документации функций из классов стандартной библиотеки обычно указано, какой уровень гарантии они обеспечивают. Рассмотрим, например, гарантии безопасности класса std::vector.

• Деструктор, функции empty, size, capacity, а также clear предоставляют гарантию отсутствия сбоев.

• Функции push_back и resize предоставляют строгую гарантию.

• Функция insert предоставляет лишь базовую гарантию. Можно было бы сделать так, чтобы она предоставляла строгую гарантию, но за это пришлось бы заплатить её эффективностью: при вставке в середину вектора пришлось бы делать реаллокацию.

Функции класса, которые гарантируют отсутсвие сбоев, следует помечать ключевым словом noexcept:

class C {
public:
    void f() noexcept {
        // ...
    }
};

С одной стороны, эта подсказка позволяет компилятору генерировать более эффективный код. С другой — эффективно обрабатывать объекты таких классов в стандартных контейнерах. Например, std::vector<C> при реаллокации будет использовать конструктор перемещения класса C, если он помечен как noexcept. В противном случае будет использован конструктор копирования, который может быть менее эффективен, но зато позволит обеспечить строгую гарантию безопасности при реаллокации.