Каким образом реализуют наследование классов ошибок

ВикиЧтение

C++ для начинающих
Липпман Стенли

Though this question is rather old and has already been answered plenty, I just want to add a note on how to do proper exception handling in C++11, since I am continually missing this in discussions about exceptions:

Use std::nested_exception and std::throw_with_nested

It is described on StackOverflow here and here, how you can get a backtrace on your exceptions inside your code without need for a debugger or cumbersome logging, by simply writing a proper exception handler which will rethrow nested exceptions.

Since you can do this with any derived exception class, you can add a lot of information to such a backtrace!
You may also take a look at my MWE on GitHub, where a backtrace would look something like this:

Library API: Exception caught in function 'api_function'
Backtrace:
~/Git/mwe-cpp-exception/src/detail/Library.cpp:17 : library_function failed
~/Git/mwe-cpp-exception/src/detail/Library.cpp:13 : could not open file "nonexistent.txt"

You don’t even need to subclass std::runtime_error in order to get plenty of information when an exception is thrown.

The only benefit I see in subclassing (instead of just using std::runtime_error) is that your exception handler can catch your custom exception and do something special. For example:

try
{
  // something that may throw
}
catch( const MyException & ex )
{
  // do something specialized with the
  // additional info inside MyException
}
catch( const std::exception & ex )
{
  std::cerr << ex.what() << std::endl;
}
catch( ... )
{
  std::cerr << "unknown exception!" << std::endl;
}

Though this question is rather old and has already been answered plenty, I just want to add a note on how to do proper exception handling in C++11, since I am continually missing this in discussions about exceptions:

Use std::nested_exception and std::throw_with_nested

It is described on StackOverflow here and here, how you can get a backtrace on your exceptions inside your code without need for a debugger or cumbersome logging, by simply writing a proper exception handler which will rethrow nested exceptions.

Since you can do this with any derived exception class, you can add a lot of information to such a backtrace!
You may also take a look at my MWE on GitHub, where a backtrace would look something like this:

Library API: Exception caught in function 'api_function'
Backtrace:
~/Git/mwe-cpp-exception/src/detail/Library.cpp:17 : library_function failed
~/Git/mwe-cpp-exception/src/detail/Library.cpp:13 : could not open file "nonexistent.txt"

You don’t even need to subclass std::runtime_error in order to get plenty of information when an exception is thrown.

The only benefit I see in subclassing (instead of just using std::runtime_error) is that your exception handler can catch your custom exception and do something special. For example:

try
{
  // something that may throw
}
catch( const MyException & ex )
{
  // do something specialized with the
  // additional info inside MyException
}
catch( const std::exception & ex )
{
  std::cerr << ex.what() << std::endl;
}
catch( ... )
{
  std::cerr << "unknown exception!" << std::endl;
}

В
С#
имеется возможность обрабатывать
исключения, создаваемые программистом.
В своих программах вы можете использовать
для обработки ошибок «собственные»
исключения. Для этого достаточно
определить класс как производный от
класса Exception.
Как правило, определяемые программистом
исключения, должны быть производными
от класса ApplicationException,
«родоначальника» иерархии,
зарезервированной для исключений,
связанных с прикладными программами.
Созданные вами производные классы не
должны ничего реализовывать, поскольку
одно лишь их существование в системе
типов уже позволит использовать их в
качестве исключений.

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

//
Создание пользовательского исключения
для

//
обнаружения ошибок при работе с объектами
класса

//
RangeArray.

using
System;

//
Создаем исключение для класса RangeArray.

class
RangeArrayException : ApplicationException {

//
Реализуемстандартныеконструкторы,

public
RangeArrayException() : base() { }

public
RangeArrayException(string str) : base(str) { }

//
Переопределяемметод
ToString()длякласса

//
RangeArrayException.

public
override string ToString() {

return
Message;

}}

//
Улучшенная версия класса RangeArray.

class
RangeArray {

//
Закрытые данные.

int[]
а; // Ссылка на базовый массив.

intlowerBound;
// Наименьший индекс.

intupperBound;
// Наибольший индекс.

intlen;
// Базовая переменная для свойства
Length.

//
Создаем массив с заданным размером,

public
RangeArray(int low, int high) {

high++;

if(high
<= low) {

throw
new RangeArrayException(

«Нижний
индекс не меньше верхнего.»),

}

а
= new int[high — low];

len
= high — low;

lowerBound
= low;

upperBound
= —high;

}

//
Свойство Length,
предназначенное только для чтения,

public
int Length {

get
{

return
len;

}}

//
Индексатор для объекта класса RangeArray.

public
int this[int index] {

//
Средство для чтения элемента массива,

get
{

if(ok(index))
{

return
a[index — lowerBound];

}
else {

throw
new RangeArrayException(

«Ошибка
нарушения границ диапазона.»);

}}

//
Средство для записи элемента массива.-

set
{

if(ok(index))
{

a[index
— lowerBound] = value;

}

else
throw new RangeArrayException(

«Ошибка
нарушения границ диапазона.»);

}}

//
Метод возвращает значение true,

//
если индекс в пределах диапазона,

private
bool ok(int index) {

if(index
>= lowerBound & index <= upperBound)

returntrue;

returnfalse;

}}

//
Демонстрируем использование массива
с заданным

//
диапазоном изменения индекса,

classRangeArrayDemo
{

public
static
void
Main()
{

try
{

RangeArray
ra = new RangeArray(-5, 5);

RangeArrayra2
= newRangeArray(1,
10);

//
Демонстрируем использование объекта-массива
га.

Console.WriteLine(«Длина
массива га: » + ra.Length);

for(int
i = -5; i <= 5; i++)

ra[i]
= i;

Console.Write(«Содержимое
массива ra:
» ) ;

for(int
i = -5; i <= 5; i++)

Console.Write(ra[i]
+ » » ) ;

Console.WriteLine(«n«);

//
Демонстрируем использование объекта-массива
ra2.

Console.WriteLine(«Длина
массива ra2: » + ra2.Length);

for(int
i = 1; i <= 10; i++)

ra2[i]
= i;

Console.Write(«Содержимое
массива ra2:
«) ;

for(int
i = 1; i <= 10; i++)

Console.Write(ra2[i]
+ » » ) ;

Console.WriteLine(«n»);

}
catch (RangeArrayException exc) {

Console.WriteLine(exc);

}

//
Теперь демонстрируем «работу над
ошибками».

Console.WriteLine(

«Сгенерируем
ошибки непопадания в диапазон.»);

//
Используем неверно заданный конструктор,

try
{

RangeArray
ra3= new RangeArray(100, -10); // Ошибка!

}
catch (RangeArrayException exc) {

Console.WriteLine(exc);

}

//
Используем неверно заданный индекс,

try
{

RangeArray
ra3 = new RangeArray(-2, 2);

for(int
i = -2; i <= 2; i++)

гаЗ
[i] = i;

Console.Write(«Содержимое
массива
ra3: » ) ;

for(int
i = -2; i <= 10; i++) // Ошибка непопадания

//
в диапазон.

Console.Write(ra3[i]
+ » » ) ;

}
catch (RangeArrayException exc){

Console.WriteLine(exc);

}}

При
выполнении этой программы получаем
такие результаты:

Длина
массиваra:
11

Содержимое
массива ra:
— 5 — 4 — 3 — 2 — 1 0 1 2 3 4 5

Длина
массива ra2:
10

С
о д е р ж и м о е м а с с и в а ra2
: 1 2 3 4 5 6 7 8 9 1 0

Сгенерируем
ошибки непопадания в диапазон.

Нижний
индекс не меньше верхнего.

Содержимое
массива raЗ:
— 2 — 1 0 1 2 Ошибка нарушения границ диапазона.

При
возникновении ошибки нарушения границ
диапазона RangeArray-объект генерирует
объект типа RangeArrayException. Этот класс —
производный от классаApplicationException. Класс
исключений, создаваемыйпрограммистом,
обычно выводится из класса
ApplicationException. Обратите внимание на то,
что подобная ошибка может обнаружиться
во время созданияRangeArray-объекта. Чтобы
перехватывать такие исключения, объекты
классаRange Array должны создаваться внутри
блока try, как это показано в программе.
Сиспользованием исключений для сообщений
об ошибках класс RangeArray теперьнапоминает
один из встроенных С#-типов и может быть
полностью интегрирован вмеханизм
обработки исключений любой программы.

В 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. В противном случае будет использован конструктор копирования, который может быть менее эффективен, но зато позволит обеспечить строгую гарантию безопасности при реаллокации.

Пытаюсь написать свой класс исключений

class MathException : std::exception
{
public:
    MathException(std::string &&whatStr) noexcept : whatStr(std::move(whatStr)) { }
    MathException(const std::string &whatStr) noexcept : whatStr(whatStr) { }
    ~MathException() noexcept;

    const char* what() const noexcept override;

private:
    std::string whatStr;
};

const char* MathException::what() const noexcept
{
    return whatStr.c_str();
}

int main()
try
{
    throw MathException("Parse Error");
}
catch(...)
{

}

На что мне компилятор вежливо отвечает:

error: undefined reference to 'typeinfo for MathException'                                                                                                                                
error: undefined reference to 'MathException::~MathException()'                                                                                                                           
error: undefined reference to 'vtable for MathException'                                                                                                                                             
the vtable symbol may be undefined because the class is missing its key function (see go/missingkeymethod) 

Исключительные ситуации

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

Для обработки исключений в языке С# примененяются следующие ключевые слова: try, catch, throw, finally. Перечисленные ключевые слова образуют взаимосвязанную подсистему, в которой использование одного из ключевых слов влечет за собой использование других.

Обработка исключений в языке C# реализуется на основе операторных блоков try и catch.

Описание блока try и catch

Синтаксис:

try {
Блок_кода_для_которого_выполняется
мониторинг_ошибок}
catch (ExcepTypel ехОb) 
    { Обработчик_исключений_ExcepTypel }
catch (ЕхсерТуре2 ехОb) 
    {Обработчик_исключений_ЕхсерТуре2 }

Основные системные исключения приведены в таблице 10.

Тип исключения в операторе catch должен соответствовать типу перехватываемого исключения. Неперехваченное исключение непременно приводит к досрочному прекращению выполнения программы.

Для выполнения перехвата исключений вне зависимости от их типа (перехват всех исключений) возможно использование оператора catch без параметров.

Возврат из исключения

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

С целью предотвращения этой ситуации возможно указание блока кода, который вызывается после выхода из блока try / catch, с помощью блока finally в конце последовательности try / catch.

Конструкция try/catch с блоком finally

Синтаксис:

try {
// Блок кода, выполняющий мониторинг ошибок
}
catch (ExcepTypel ех1) {
//1 Обработка исключения ExcepTypel. 
}

catch (ЕхсерТуре2 ех2) {
// 2 Обработка исключения ЕхсерТуре2 .
finally {
// Код блока finally. 
}

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

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

Исключения автоматически генерируются средой программирования. Однако исключение может быть и явно сгенерировано посредством оператора throw.

Оператор throw

Синтаксис:

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

Наследование классов исключений

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

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

Порядок выполнения работы

1. Реализовать программу на языке C# в соответствии с вариантом исполнения.
2. Графически проиллюстрировать место реализованного исключения в общей иерархии.

Варианты заданий

Реализовать обработку ошибок для лабораторной работы №9, при этом переопределив с помощью наследования событие:

1. StackOverflowException
2. ArrayTypeMismatchException
3. DivideByZeroException
4. IndexOutOfRangeException
5. InvalidCastException
6. OutOfMemoryException
7. OverflowException

У вас в оригинальной иерархии классов класс Exception является абстрактным, т.к. его метод GetError объявлен как pure virtual (т.е. = 0). Я не хотел менять эту деталь — раз вы захотели, чтобы Exception был абстрактным классом, то пусть так и будет.

Однако в моей реализации метод GetError получает вполне реальное определение. Синтаксис языка С++ не позволяет одновременно, прямо в определении класса объявлять метод как = 0 и тут же сразу предоставлять определение этого метода. В таких случаях, если вы хотите предоставить определение для = 0 метода, это определение приходится волей-неволей выносить за пределы класса.

Что я и сделал.

А то, что этот метод у меня явно объявлен как inline… Так и у вас в коде все методы являются inline. Методы, которые определены прямо в определении класса, являются inline даже без явного указания слова inline. Я в этом случае поставил в определение слово inline не для того «что бы программа работала быстрее», а просто для того, чтобы сохранить единообразие с тем, что уже и так написано у вас. Фактически это вы выбрали inline, а не я.

—

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