
- •2 Часть
- •1 Приближение
- •1.1 Бросание(генерация) исключений
- •1.2 Пример 1. Поддержка инкапсуляции
- •1.3 Ловля исключений
- •2 Приближение
- •2.1 Развитие способов обработки ошибок
- •1. Хочется, чтобы приложение как можно быстрее упало и не успело сделать ничего плохого.
- •2. Хочется, чтобы перед своей кончиной приложение напечатало нечто, позволяющее понять, что не так.
- •2.2 Преимущества использования исключений
- •2.4 Пример 2. Исключение и память, проброс
- •3.3 Отладка и исключения в Visual Studio. Stack trace
- •3.4 Как развивался концепт с исключениями дальше?
- •3.4.2 Сборщик мусора
- •3.5 Общие замечания по созданию исключительных ситуаций
- •3.6 Код всегда должен писаться, чтобы быть устойчивым к исключениям [1]
3.5 Общие замечания по созданию исключительных ситуаций
Когда у вас появится опыт по работе с исключениями длиной в месяца 4-6, можете загуглить в интернете Best practices for exceptions.
https://msdn.microsoft.com/en-us/library/seyhszts%28v=vs.110%29.aspx
1. Пишите код так, чтобы при обычном нормальном использовании ваших классов, исключения не возникали.
Пример:
class BadStack { public: int Pop() { if (Empty()) throw exception("Not enough space.");
// ... }
// ... }; |
class GoodStack { public: bool IsEmpty() { //... }
int Pop() { if (Empty()) throw exception("Not enough space.");
// ... }
// ... }; |
2. Вместо возврата кода с ошибкой однозначно стоит предпочитать исключения.
3. В качестве экземпляров исключений используйте классы, которые уже есть в языке. Потребность плодить новые возникает редко.
4. Классы, которые унаследованы от исключений, нужно заканчивать на Exception. Например FtpException.
5. Используйте в качестве сообщения грамматически корректное предложение и правильную пунктуацию. Пример:
File example.txt was not found.
6. Перед тем, как бросить исключение, надо почистить за собой, например выделенную память и так далее.
3.6 Код всегда должен писаться, чтобы быть устойчивым к исключениям [1]
В коде должны использоваться подпрограммы, которые обеспечивают базовые гарантии. Базовая гарантия: подпрограмма почистит за собой, если внутри нее произойдет исключение. Если какие-то подпрограммы не соответствуют этому принципу, их надо дописать. (сильная гарантия – система может продолжать функционировать)
Весь код рассматривается как код, который может бросить исключения, если иное заранее не известно.
Весь код, который мы пишем, должен обеспечивать как минимум базовые гарантии.
Если код, который мы пишем, никогда не кинет исключение, мы должны это задокументировать no-throw.
В нужных ситуациях нужно обеспечивать сильные гарантии.
Каждый элемент (функция или тип) должен заниматься только одним делом.
Каждый класс должен заниматься управлением только одного ресурса.
По возможности должны использоваться умные указатели, типа shared_ptr.
3.7 C++ 11
1) Исключения стало можно передавать между потоками.
Появилась подпрограмма current_exception() которая получает текущее исключение.
2) Nested исключения. Иногда нужно выбросить наверх функции исключение, агрегированное в другое исключение. Пример – библиотека для работы с Ftp. Наверх прокидываются только FtpException, а реальное исключение внутри находится.
Список использованных источников
[1] Exception-Safe Code [Electronic resource] / Jon Kalb. – Mode of access: https://www.youtube.com/watch?v=W7fIy_54y-w. – Date of access: 01.02.2015.