Ошибка при выполнении файловой операции std exception - Исправление ошибок и поиск оптимальных решений проблем

Содержание:

1. Об ошибке при выполнении файловой операции

2. Устранение «Ошибки при выполнении файловой операции» в 1С 8.3

1. Об ошибке при выполнении файловой операции

Приветствую, коллеги! В данной статье будет описана ошибка «Ошибка при выполнении файловой операции», и подробно рассмотрены способы ее устранения.

Когда происходит обновление конфигураций в 1С 8, по завершении обновления, часто появляется ошибка, которая гласит «Ошибка при выполнении файловой операции – файл не содержит доступных обновлений».

2. Устранение «Ошибки при выполнении файловой операции» в 1С 8.3

Рассмотрим методы, при помощи которых, можно устранить ошибку при выполнении файловой операции в 1С.

Итак, первый способ – это попробовать сделать обновление при помощи файлов по обновлению вида «релиз 1с*.cfu». Если это не помогло, то можно попробовать обновить систему при помощи общего файла вида «полный релиз 1С*.cf».

Вторым способом будет проверка на соответствие общей версии системы 1С с минимальными требованиями версии конфигурации 1С, которую обновляем.

Третий способ устранения ошибки при выполнении файловой операции в 1С – более сложный, но действенный. Необходимо открыть в конфигурацию от поставщика в режиме Конфигуратора. Если ошибка всё так же появляется, то необходимо удалить конфигурацию поставщика, а затем опять установить. По сути, в данном варианте «вытягивается» последняя, рабочая версия данной конфигурации и обновление будет завершено без ошибок.

Рассмотрим подробнее третий способ. Пусть у нас уже есть некоторая конфигурация 1С KORG 1-ой версии, которая работает, но нужно поставить 2-ю версию, то есть обновить версию конфигурации 1С 8.3. Когда происходит обновление, всплывает ошибка «Ошибка при выполнении файловой конфигурации». Порядок действий в этом случае:

1. скачать релиз 1С KORG с версией 1*.cf;

2. копируем нашу базу данных;

3. в конфигураторе, который соответствует обновляемой базе, переходим по пути: «Конфигурация → Поддержка → Настройки поддержки → Снять с поддержки». В случае, если кнопка для снятия с поддержки недоступна, необходимо сперва включить возможные изменения. После этого нужно дать согласие, если система 1С будет уточнять что-либо или подтверждать действия;

4. Далее переходим по следующему пути: «Конфигурация → Сравнить и объединить с конфигурацией из файла…». Здесь необходимо выбрать файл «полный релиз 1С KORG версии 1*.cf»;

5. Далее перед нами появится окно, в котором система 1С будет запрашивать постановление на учёт для поддержки, на это уведомление обязательно отвечаем согласием;

6. В случае, если наша конфигурация является типовой, откроется окно по сравнению конфигураций. В нем обязательно убираем все «галочки». Далее последует объединение конфигураций;

7. В новом окне кликаем на «Сохранить изменения»;

8. Ещё раз сохраняем базу данных;

9. Обновляем конфигурацию 1С стандартным способом.

Если всё сделать, согласно инструкции выше, то в вашей конфигурации 1С 8.3 «Ошибка при выполнении файловой операции» больше не возникнет. Спасибо за внимание!

Специалист компании «Кодерлайн»

Айдар Фархутдинов

Источник

Обновлено 15.10.2020

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов Рунета Pyatilistnik.org. В прошлый раз мы с вами разобрали, что из себя представляет файловая система raw, и как ее исправить, чтобы восстановить свои данные. Двигаемся дальше и поговорим сегодня на тему капризности 1С, точнее на капризную работу в рамках Windows Server 2016. Я рассмотрю причину и устранение периодически повторяющейся ошибки на сервере 1С 8.3 «Ошибка при выполнении файловой операции«. Ее я стал встречать после обновления с Windows Server 2012 R2 д 2016. Думаю мой опыт сэкономит вам часик серфинга по интернету.

Описание проблемы

В моей компании заканчивается обновление операционных систем у виртуальных серверов, с Windows Server 2012 R2 на Windows Server 2016, я понимаю, что поддержка первых еще будет несколько лет, но хочется уже не делать это в последний момент, а слегка опережать, да и уже давно пора стремиться к Windows Server 2019. Сервера 1С не были исключением, обновление происходило по быстрому варианты. Тут подразумевается накатывание более новой версии ОС по верх старой, тут мы убивали двух зайцев:

Получали свежую версию ОС
Оставляли весь софт на сервере, и не требовалась его переустановка

В случае чего всегда можно было откатиться из снапшота на момент проведения работ, благо ESXI 6.5 это помогает делать в два клика. Все прекрасно обновилось и сервер зажил новой жизнью. В какой-то момент при запуске клиента 1С 8.3 на RDS ферме, стала появляться ошибка:

Ошибка при выполнении файловой операции

Устранение проблемы

Начав изучать данный вопрос мы не стали откатываться к бэкапу, так как данная проблема возникала не постоянно, а через некоторые промежутки и была вызвана явно не переходом на более новую версию операционной системы. Подняв исторические данные в системе заявок, я нашел похожую, где решением ошибки был перенос базы данных 1С на другой диск. Меня это заинтересовало и я стал прикидывать, что же могло быть в той ситуации. Через минут 20 я нашел одну закономерность, что на всех проблемных хостах был установлен компонент Windows дедупликации, как раз на тех дисках, где располагались базы данных 1С.

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

Вывод: Windows Дедупликация и 1С просто не совместимы друг с другом, это нужно запомнить

Из дополнительных методов я могу вам посоветовать еще очистку кэша 1С. Еще в на умных сайтах советуют на серверах, где используется 1С отключать протокол IPv6 на сетевых интерфейсах, но лично я не понимаю этого прикола, так как сама Microsoft советует по возможности этого не делать, в виду того, что очень многие ее сервисы и компоненты Windows в приоритете используют именно его, меньше будет проблем с DNS и Active Directory.

Вообще если у вас виртуальные сервера лежат на системе хранения данных, то у нее должна быть своя функция дедупликации и использовать лучше и правильнее ее. Если у вас есть другие варианты решения данной проблемы, то пишите их в комментариях. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Источник

Ошибка при выполнении файловой операции

zoran

09.06.21 — 15:35

Приветствую, уважаемые форумчане.

Поделитесь, пожалуйста, опытом, может кто сталкивался. Из-за чего может возникать ошибка: «Ошибка при выполнении файловой операции ‘C:UsersUSR1CV8AppDataLocalTempv8_1BF4_352.mxl'». Ошибка происходит при попытке открыть элемент справочника. Ошибка не постоянная, может появиться, а может и нет. База на SQL. Сервер виртуальный. Очень напрягает такая ситуация, особенно, если непонятная причина.

mikecool

1 — 09.06.21 — 15:37

смотри, что у тебя при открытии происходит, видимо коряво отчет формируется

zoran

2 — 10.06.21 — 11:05

(1) При открытии нашел место кода, где пишется в этот временный файл. Но проблема то несколько в ином, в том, что в один момент времени все без ошибок, а в другой момент времени выдает эту ошибку. Вот и хотим понять, на чьей стороне ошибка: диск виноват (хоть и виртуальный), права на каталог «тупят» (хотя всем дали полные) или что-то другое, неизвестное пока. Может был у кого прецедент и выяснили причину?

1Сергей

3 — 10.06.21 — 12:56

(2) Места хватает на сервере?

zoran

4 — 10.06.21 — 13:03

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

Kassern

5 — 10.06.21 — 13:04

(0) может файл занят а с ним какие то манипуляции хотите сделать. Когда он не занят, то работает, когда не успевает его освободить, тогда ошибку ловите.

zoran

6 — 10.06.21 — 13:06

(5) Так он вроде только при данном событии создается (при открытии элемента справочника, в смысле), а затем тут же удаляется.

1Сергей

7 — 10.06.21 — 13:08

(6) всегда с одним и тем же именем? А если двое отчет откроют?

ДенисЧ

8 — 10.06.21 — 13:10

(7) Видно же, что это временный файл…

Kassern

9 — 10.06.21 — 13:11

(6) ругается при создании, или при удалении?

Kassern

10 — 10.06.21 — 13:13

(6) если не секрет, для чего вы временный файл создаете, что там такого специфического, чего нельзя во временное хранилище пихнуть?

zoran

11 — 10.06.21 — 13:25

(7) Разный

zoran

12 — 10.06.21 — 13:26

(9) Пишет, что при вызове Write

zoran

13 — 10.06.21 — 13:27

(10) Конфигурация специализированная, 1С Отель. Разработчики так сделали

Kassern

14 — 10.06.21 — 13:29

(13) а что на это говорят разработчики этого чудо решения?

Kassern

15 — 10.06.21 — 13:32

(12) если код не большой, где этот временный файл создается, пишется и удаляется, то можете сюда кусок скинуть, либо на пастебин ссылкой. Возможно там где-нить в коде косяк.

zoran

16 — 10.06.21 — 13:58

(14) Отмалчиваются

zoran

17 — 10.06.21 — 13:58

(15)

Function cmGetAbsoluteColor(pColor)    Export

    If pColor.Type = ColorType.Absolute Then

        Return pColor;

    EndIf;

    vSD = New SpreadsheetDocument;

    vSD.Area(«R1C1»).BackColor = pColor;

    vTF = GetTempFileName(«mxl»);

    vSD.Write(vTF, SpreadsheetDocumentFileType.MXL7);

    vSD.Read(vTF);

    vColor = vSD.Area(«R1C1»).BackColor;

    vSD = Undefined;

    DeleteFiles(vTF);

    Return vColor;

EndFunction

1Сергей

18 — 10.06.21 — 13:59

(17) расстрелять!

Kassern

19 — 10.06.21 — 14:11

(17) И это все, для того чтобы вернуть цвет ячейки… Может у вас ошибка каждый раз когда pColor.Type <> ColorType.Absolute?

DrZombi

20 — 10.06.21 — 14:18

(0) Предлагаю, не писать этот файл

DrZombi

21 — 10.06.21 — 14:21

(17) Этот ужас, где пишется?

На клиенте или Сервере?

1Сергей

22 — 10.06.21 — 14:23

(15)

Function cmGetAbsoluteColor(pColor)    Export

    //If pColor.Type = ColorType.Absolute Then

    //    Return pColor;

    //EndIf;

    //vSD = New SpreadsheetDocument;

    //vSD.Area(«R1C1»).BackColor = pColor;

    //vTF = GetTempFileName(«mxl»);

    //vSD.Write(vTF, SpreadsheetDocumentFileType.MXL7);

    //vSD.Read(vTF);

    //vColor = vSD.Area(«R1C1»).BackColor;

    //vSD = Undefined;

    //DeleteFiles(vTF);

    //Return vColor;

    Возврат Новый Цвет(255, 255, 255);

EndFunction

С Вас сто рублёв

1Сергей

23 — 10.06.21 — 14:23

(22) -> (17)

zoran

24 — 10.06.21 — 14:30

(19) Проверил в отладчике. Когда не равен, проскакивает без ошибок.

Kassern

25 — 10.06.21 — 14:32

(23) New Color() же)

zoran

26 — 10.06.21 — 14:32

(21) Это в общем модуле, на сервере

1Сергей

27 — 10.06.21 — 14:36

(25) не скрепно

DrZombi

28 — 10.06.21 — 14:39

(0) Ну народ, уже давно не пишут, все через память :)))

&НаСервере

Function cmGetAbsoluteColor(pColor) Export

    If pColor.Вид = ВидЦвета.Абсолютный Then

        Return pColor;

    EndIf;

Поток = Новый ПотокВПамяти();

    vSD = Новый ТабличныйДокумент;

    vSD.Область(«R1C1»).ЦветФона = pColor;

    vTF = ПолучитьИмяВременногоФайла («mxl»);

    vSD.Записать(Поток, ТипФайлаТабличногоДокумента.MXL7);

Поток.Перейти(0,ПозицияВПотоке.Начало);

    vSD.Прочитать(Поток, СпособЧтенияЗначенийТабличногоДокумента.Значение);

    vColor = vSD.Область(«R1C1»).BackColor;

vSD = Неопределено;

//УдалитьФайлы(vTF);

Return vColor;

EndFunction

DrZombi

29 — 10.06.21 — 14:39

+(28) Ну поток уж сам закроешь

DrZombi

30 — 10.06.21 — 14:40

+ (0) Вот получше так…

&НаСервере

Function cmGetAbsoluteColor(pColor) Export

    If pColor.Вид = ВидЦвета.Абсолютный Then

        Return pColor;

    EndIf;

Поток = Новый ПотокВПамяти();

    vSD = Новый ТабличныйДокумент;

    vSD.Область(«R1C1»).ЦветФона = pColor;

vSD.Записать(Поток, ТипФайлаТабличногоДокумента.MXL7);

Поток.Перейти(0,ПозицияВПотоке.Начало);

    vSD.Прочитать(Поток, СпособЧтенияЗначенийТабличногоДокумента.Значение);

    vColor = vSD.Область(«R1C1»).BackColor;

    Поток.Закрыть();

    Поток = Неопределено;

    vSD = Неопределено;

//УдалитьФайлы(vTF);

Return vColor;

EndFunction

Kassern

31 — 10.06.21 — 14:42

(29) ну это ладно, что mxl, а если бы xlsx был то в потоке уже так просто табдок не прочитаешь…

DrZombi

32 — 10.06.21 — 14:43

(31) У нас не ексель

DrZombi

33 — 10.06.21 — 14:43

+ Вот будет ексель, тогда и поговорим про скорость

Kassern

34 — 10.06.21 — 14:44

(33) я одного понять не могу, чем создателей webцвета не устроили или различные типовые стили?

DrZombi

35 — 10.06.21 — 14:45

(34) Ненаю, где там это используется, я вот еще не пойму, нак-зачемой по англиски писать

DrZombi

36 — 10.06.21 — 14:46

+ Потом даже модифицировать не могут

Kassern

37 — 10.06.21 — 14:47

(35) может у индусов заказывали конфу?))

zoran

38 — 10.06.21 — 14:47

(35) Там вся конфа такая. Специально похоже, чтобы сложнее было понять, что они там разработали)

DrZombi

39 — 10.06.21 — 14:51

(38) Соболезную, держи пример, не мучайся хоть со справочником

zoran

40 — 10.06.21 — 14:53

Кстати, не только mxl пишут. Есть внешний ресурс Travelline, к которому 1С коненктится, забирает инфу и создает брони в 1С. При этом так же периодически ошибки вываливаются такого типа: «Failed to create reservation: Ошибка при выполнении файловой операции ‘C:UsersUSR1CV8AppDataLocalTempБронь_9719.pdf’; Booking №:20210613-19260-96172841».

zoran

41 — 10.06.21 — 14:54

Вопрос изначальный по идее так и остается. По какой причине то проходит запись в Temp, то нет. Бред какой-то происходит.

DrZombi

42 — 10.06.21 — 14:54

(40) Подвиг за день не должен превышать больше одного… Это вы дальше сами

zoran

43 — 10.06.21 — 14:54

(42)

DrZombi

44 — 10.06.21 — 14:55

(41) Если оба юзвера или много считывают, то может быть так, что у всех одно и тоже временное имя, 1С… что сказать

Kassern

45 — 10.06.21 — 14:56

(40) тоже наверное можно без создания временного файла обойтись.

zoran

46 — 10.06.21 — 14:58

(44) Интересное предположение. Может так и происходит на самом деле

DrZombi

47 — 10.06.21 — 14:59

(46) Код покажи, вот этого (40) — Чисто в познавательных целях

Kassern

48 — 10.06.21 — 14:59

(46) создайте свою папочку на серваке и дайте к ней доступ. Сами контролируйте уникальность файлов. Либо вообще поправьте код, чтобы избыточные временные файлы не создавались.

SSSSS_AAAAA

49 — 10.06.21 — 15:00

(41) Про антивирус уже писали?

Kassern

50 — 10.06.21 — 15:00

(47) скорее всего возвращается ссылка на pdf брони созданной, а ее пытаются во временном файле записать)

DrZombi

51 — 10.06.21 — 15:01

+(46) Вот тебе генератор имен.

Функция УникальноеИмя(расширение)

Возврат «» + КаталогВременныхФайлов() + СокрЛП(Новый УникальныйИдентификатор())+».»+расширение;

КонецФункции

Kassern

52 — 10.06.21 — 15:06

(51) а вот тут почитаешь и 1ска тебе тыкает, что так делать не надо, только для веб клиента)

https://its.1c.ru/db/v8std/content/542/hdoc

Kassern

53 — 10.06.21 — 15:07

(52) тут понимаешь ли 1ской все гарантируется и должно работать)

DrZombi

54 — 10.06.21 — 15:09

(52) Если по каким-то причинам прикладной код не удалит созданный файл (например, между блоками создания и удаления временного файла возникнет штатное или нештатное исключение), этот файл так и останется в каталоге временных файлов.

…

А теперь вопрос, какой метод от 1С, удалит все временные файлы на сервере?

На сервере, где так же есть такая вещь, как КЭШ сервера

Kassern

55 — 10.06.21 — 15:10

(54) вроде бы перезапуск службы 1с это делать должен)

DrZombi

56 — 10.06.21 — 15:11

(54) >>> Если по каким-то причинам прикладной код не удалит созданный файл

Файл в любом случаи останется

…Или 1С так же повторно заюзает этот файл?

DrZombi

57 — 10.06.21 — 15:11

(55) Что? Вы хотите сказать, что при рестарте службы, у многих пользователей автоматом гарантировано все ляжет? :)))

DrZombi

58 — 10.06.21 — 15:13

+(55) и тут же 1С разрешает этот код в (51) для вэба :))))

3.1. При выполнении кода веб-клиентом метод ПолучитьИмяВременногоФайла недоступен. Поэтому для формирования имен временных файлов и каталогов необходимо использовать функцию КаталогВременныхФайлов и объект УникальныйИдентификатор.

Неправильно:

Каталог = КаталогВременныхФайлов();

ИмяФайла = «TempDataFile.xml»;

ИмяПромежуточногоФайла = Каталог + ИмяФайла;

Данные.Записать(ИмяПромежуточногоФайла);

Правильно:

Каталог = КаталогВременныхФайлов();

ИмяФайла = Строка(Новый УникальныйИдентификатор) + «.xml»;

ИмяПромежуточногоФайла = Каталог + ИмяФайла;

Данные.Записать(ИмяПромежуточногоФайла);

zoran

59 — 10.06.21 — 15:16

(47) Вот этот кусок кода:

    vConfirmationFileName = StrReplace(vDocObj.Ref.Metadata().Presentation() + » » + Format(vDocObj.GuestGroup.Code, «ND=12; NFD=0; NG=»), » «, «_») + «.pdf»;

    vConfirmationFilePath = cmGetFullFileName(vConfirmationFileName, TempFilesDir());

    vConfirmationSpreadsheet.Write(vConfirmationFilePath, SpreadsheetDocumentFileType.PDF);

Kassern

60 — 10.06.21 — 15:16

(58) я про это и пишу, что для только для вэба и можно. По идее, когда сеанс перезапускается, который создавал временный файлы, то они подчищаются. Если же перезапустить службу 1ски, то все сеансы схлопнутся, все временные файлы созданные в этих сеансах должны удалиться платформой.

Kassern

61 — 10.06.21 — 15:18

(59) а где гарантия, что vConfirmationFileName уникально? Если к примеру 2 человека одновременно этот кусок кода выполнят.

Kassern

62 — 10.06.21 — 15:20

(59) может у вас действительно, что то с правами на серваке? Пробовали на другой машинке базу развернуть?

zoran

63 — 10.06.21 — 15:39

(62) К сожалению нет такой возможности.

DrZombi

64 — 10.06.21 — 17:12

(59) Проблемы, т.к. нам тут не видно.

1. Что это за код и до какой степени он уникален? «vDocObj.GuestGroup.Code»

2. Для чего это пишут в формате PDF?

3. Вопрос из (61), а где гарантия?

DrZombi

65 — 10.06.21 — 17:12

(60) Сколько раз перезапускал, такого не замечал

DrZombi

66 — 10.06.21 — 17:15

+(60) Если Автор (0) гарантирует, что будет удалять такие файлы САМ, то вероятность зависших файлов равна ничтожному проценту.

Т.е. парочка файлов просочится, но не более.

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

Вот все что там пишется, зависает, не стоит и ломаной десятины…

Главное Серверу 1С не жадничать дискового пространства под его временные файлы

DrZombi

67 — 10.06.21 — 17:17

+(59) А проверки на то, что файл уже есть, тоже присутствуют?

DrZombi

68 — 10.06.21 — 17:18

Кода мало, давай под 1000 строк

DrZombi

69 — 10.06.21 — 17:18

Не жадничай

Kassern

70 — 10.06.21 — 17:58

(67) да какая там проверка, все же тут есть:

vConfirmationFilePath = cmGetFullFileName(vConfirmationFileName, TempFilesDir()); создали путь во временном каталоге

vConfirmationSpreadsheet.Write(vConfirmationFilePath, SpreadsheetDocumentFileType.PDF); записали табдок по этому пути в формате пдф.

DrZombi

71 — 11.06.21 — 06:34

(70) Если так, то это жесть :)))

zoran

72 — 22.06.21 — 09:02

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

Источник

Продолжаем разговор об исключениях в C++.

Гарантии безопасности
Спецификации исключений в C++
Стоит ли избегать исключений
Как работают исключения
Заключение
Полезные ссылки

Георгий Осипов

Один из авторов курса «Разработчик C++» в Яндекс Практикуме, разработчик в Лаборатории компьютерной графики и мультимедиа ВМК МГУ

В первой части мы разобрали, как создавать исключения и работать с ними, а также какими они бывают. Разобрали ключевые слова try, catch и throw, синтаксис выбрасывания и обработки исключений, а ещё особые случаи, связанные с исключениями.

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

гарантии безопасности;
спецификации исключений;
как исключения влияют на скорость выполнения;
как устроены исключения в C++ и как они работают.

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

Углубить и систематизировать знания C++ поможет курс «Разработчик C++» в Яндекс Практикуме. Для тех, кто знает C++, но желает изучить работу по сети, Docker, Linux и множество вспомогательных инструментов, есть курс «C++ для бэкенда».

Гарантии безопасности

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

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

Выделяют четыре уровня безопасности исключений:

Гарантия отсутствия исключения. Самая сильная гарантия. Означает, что исключение возникнуть не может, а значит, ничего не сломает.
Строгая гарантия безопасности. Исключение может возникнуть, но в этом случае всё будет возвращено к тому, как было до вызова соответствующей функции. Иными словами, операция не удалась, но можно сделать вид, как будто её и не было.
Базовая гарантия безопасности. При возникновении ошибки мы не можем вернуть всё как было, но всё равно останемся в корректном состоянии. Все инварианты будут сохранены, все ненужные ресурсы освобождены, ничего не утечёт. С объектом, из-за которого возникло исключение, можно продолжать работать.
Отсутствие безопасности. Не можем гарантировать ничего. Если исключение произошло, лучше поскорее завершить работу программы.

Рассмотрим пример. Напишем собственную операцию push_back для вставки в вектор.

Гарантия отсутствия безопасности

template<class T>
class Vector {
public:
    void push_back_no_guarantee(T elem) {
        T* old = mem;

        // Возможное исключение в new не опасное:
        // мы ещё ничего не успели испортить
        mem = new T[size + 1];
        size_t old_size = size++;

        // Используем алгоритм move для перемещения всех
        // элементов из старой памяти в новую.
        // Тут может возникнуть исключение.
        std::move(old, old + old_size, mem);
        mem[old_size] = std::move(elem);

        delete[] old;
    }

private:
    T* mem = nullptr;
    size_t size = 0;
};

Вызов new не опасен в отличие от перемещения элементов: мы ничего не знаем про конструктор перемещения неизвестного объекта T. Он может выбрасывать исключение.

Эта реализация метода не даёт гарантий. Если во время перемещения объектов возникло исключение, то мы как минимум получим утечку памяти. Кроме того, у вектора будет неправильный размер, например, если перемещение прервалось на середине.

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

Базовая гарантия безопасности

Улучшим нашу функцию, чтобы подняться с четвёртого уровня безопасности на третий. Это минимальный уровень, который допустимо использовать в программах.

void push_back_basic_guarantee(T elem) {
    T* old = mem;
    mem = new T[size + 1];
    size_t old_size = size;
    size = 0;

    try {
        // Используем цикл, чтобы постоянно знать актуальный размер.
        for (size_t i = 0; i < old_size; ++i) {
            mem[i] = std::move(old[i]);
            size++;
        }
        mem[old_size] = std::move(elem);
        size++;
    }
    catch(...) {
        // Предотвратим утечку ресурсов в случае исключения
        delete[] old;
        throw;
    }

    delete[] old;
}

Уже лучше: размер вектора будет корректен, и мы не допустим утечки. Однако такая вставка может привести, например, к обнулению вектора, если исключение возникло в самом первом перемещении.

Строгая гарантия безопасности

Над строгой гарантией нужно потрудиться.

void push_back_strong_guarantee(T elem) {
    // Идём другим путём: аллоцируем память, но не будем
    // менять this->mem пока копирование не закончено.
    T* new_mem = new T[size + 1];

    try {
        for (size_t i = 0; i < size; ++i) {
            // Мы должны быть готовы всё вернуть как было, а значит, 
            // не можем перемещать элементы, чтобы не испортить 
            // старую память — придётся их копировать.
            new_mem[i] = mem[i];
        }
        // Последний элемент можно переместить:
        new_mem[size] = std::move(elem);
    }
    catch(...) {
        delete[] new_mem;
        throw;
    }

    // Выше мы вообще не меняли this.
    // Теперь, когда всё точно готово, сделаем это.
    T* old = mem;
    mem = new_mem;
    size++;

    // Считаем, что деструктор не выбрасывает.
    delete[] old;
}

У строгой гарантии есть неприятный эффект: нам пришлось отказаться от перемещений в пользу копирований. Таким образом, она отрицательно влияет на эффективность.

Можно сделать всё эффективно, если есть уверенность, что перемещение объектов типа T не выбрасывает исключений. Стандартный std::vector так и делает.

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

И наконец, достигнем вершины — напишем метод без исключений:

// Теперь метод возвращает bool:
// true показывает, что вставка удалась,
// false свидетельствует об ошибке.
bool push_back_no_exception(T elem) {
    T* new_mem;

    // Теперь нужно поймать возможный std::bad_alloc или
    // исключение в конструкторе
    try {
        new_mem = new T[size + 1];
    }
    catch(...) {
        return false;
    }

    try {
        for (size_t i = 0; i < size; ++i) {
            new_mem[i] = mem[i];
        }
        new_mem[size] = std::move(elem);
    }
    catch(...) {
        delete[] new_mem;
        return false;
    }

    T* old = mem;
    mem = new_mem;
    size++;
    
    // По-прежнему считаем, что деструктор не выбрасывает.
    delete[] old;

    return true;
}

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

Такой разный noexcept

Как говорилось выше, вставка в вектор может работать эффективнее, если есть гарантия, что перемещение объекта не выбрасывает исключений. Такую гарантию можно дать для произвольной функции, если пометить её словом noexcept:

// Функция извлечения корня будет возвращать пустое значение
// а не выбрасывать исключение. Чтобы показать, что она не выбрасывает
// мы пометили её как noexcept:
std::optional<double> SafeSqrt(double arg) noexcept {
    return arg >= 0 ? sqrt(arg) : std::nullopt;
}

Если же мы хотим явно сказать, что функция выбрасывает исключение, можно написать noexcept(false):

double UnsafeSqrt(double arg) noexcept(false) {
    return arg >= 0 
        ? sqrt(arg) 
        : throw std::invalid_argument("Попытка извлечь корень из отрицательного числа");
}

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

int f() noexcept { return 42; }
int g() { throw 42; }

constexpr bool f_is_noexcept = true;
constexpr bool g_is_noexcept = false;

// h является noexcept, только когда и f и g таковые:
int h() noexcept(f_is_noexcept && g_is_noexcept) {
    return f() + g();
}

Тут мы явно написали, какая функция noexcept, а какая — нет, хотя могли бы вычислить. noexcept допустимо использовать как операцию, определяющую, может ли выбрасывать содержимое скобок:

#include <iostream>

int f() noexcept { return 42; }
int g() { throw 42; }

constexpr bool f_is_noexcept = noexcept(f());
constexpr bool g_is_noexcept = noexcept(g());

int h() noexcept(f_is_noexcept && g_is_noexcept) {
    return f() + g();
}

int main() {
    std::cout << "Функция f может выбрасывать исключения? " << (noexcept(f()) ? "нет" : "да") << std::endl;
    std::cout << "Функция g может выбрасывать исключения? " << (noexcept(g()) ? "нет" : "да") << std::endl;
    std::cout << "Функция h может выбрасывать исключения? " << (noexcept(h()) ? "нет" : "да") << std::endl;
    
    std::cout << "Выражение f() + g() может выбрасывать исключения? " << (noexcept(f() + g()) ? "нет" : "да") << std::endl;
}

Вывод программы будет таким:

Функция f может выбрасывать исключения? нет
Функция g может выбрасывать исключения? да
Функция h может выбрасывать исключения? да
Выражение f() + g() может выбрасывать исключения? да

Заметьте, что мы пишем noexcept(g()), а не noexcept(g). Последнее выражение всегда false, поскольку само по себе выражение g ничего не делает, а значит, ничего не выбрасывает.

Если в функции, помеченной как noexcept, всё же возникло исключение, то оно приведёт к вызову std::terminate и завершению программы.

А нужен ли noexcept?

Вряд ли что-то может ответить на поставленный вопрос красноречивее бенчмарка. В этом бенчмарке, который мы провели в сервисе QuickBench, созданы три практически одинаковых класса:

F_except, у которого есть обычный конструктор перемещения;

F_noexcept, у которого конструктор перемещения помечен как noexcept;
F_noexcept2 — как F_noexcept, но с деструктором, помеченным как noexcept(false). Деструктор нужно явно помечать как noexcept(false), иначе он считается невыбрасывающим.

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

Добавление элемента в вектор в среднем в 1,6 раза быстрее, если конструктор перемещения элементов помечен как noexcept. Добавление замедляется, если деструктор элементов может выбрасывать

Отличие заметное, хотя не такое существенное из-за оптимизаций в std::vector. noexcept позволил выбрать более эффективный алгоритм, но только в том случае, когда он применялся и для конструктора перемещения, и для деструктора.

Волшебный default

Рассмотрим три класса:

class T1 {
public:
};

class T2 {
public:
    T2() {}
};

class T3 {
public:
    T4() = default;
};

Казалось бы, разницы между ними нет, но попробуем изучить конструкцию T*() на предмет выбрасывания исключений:

class T1 {
public:
};

class T2 {
public:
    T2() {}
};

class T3 {
public:
    T4() = default;
};

class T4 {
public:
    T4() noexcept {}
};

int main() {
    std::cout << std::boolalpha;
    std::cout << "T1() noexcept: " << noexcept(T1()) << std::endl;
    std::cout << "T2() noexcept: " << noexcept(T2()) << std::endl;
    std::cout << "T3() noexcept: " << noexcept(T3()) << std::endl;
    std::cout << "T4() noexcept: " << noexcept(T4()) << std::endl;
}

В этом примере мы также добавили четвёртый класс. Вывод программы такой:

T1() noexcept: true
T2() noexcept: false
T3() noexcept: true
T4() noexcept: true

Нас подвёл только один вариант, в котором конструктор объявлен как T2() {}. Такой конструктор будет считаться выбрасывающим, хотя на вид он аналогичен записи T2() = default.

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

Список исключений

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

#include <iostream>
#include <cmath>

class MyException{};

// Спецификация исключений для функции.
// Компилировать с флагом -std=c++03 или иным 
// в зависимости от компилятора
int f(int x) throw(MyException) {
    if (x < 0) 
        throw MyException();
        
    return sqrt(x);
}

int main() {
    f(15);
    f(-3);
}

У такого подхода есть преимущества:

компилятор может убедиться, что все исключения обрабатываются;
вы видите, что может, а что не может выбрасывать функция по её сигнатуре;
обработчик можно искать в compile-time.

Однако на деле не всё так радужно. Всплыл ряд недостатков:

Некоторые исключения, например, std::bad_alloc может выбрасывать почти любая функция. Везде писать throw(std::bad_alloc) утомительно.
Непонятно, как быть с указателями на функции и std::function. Если мы хотим заранее всё знать об исключениях, то спецификации исключений должны быть в типе функции. Тогда неясно, как их преобразовывать.
Можно сделать спецификации нестрогими, но тогда непонятно, что они дают.

С похожими недостатками сталкиваются и в других языках программирования. В C++ недостатки перевесили, и комитет по стандартизации решил от явных спецификаций отказаться, оставляя только noexcept. В Стандарте C++11 они объявлены устаревшими (deprecated), а позже вовсе исключены из языка.

Стоит ли избегать исключений

«Мы не используем исключения в C++», — cтайлгайд Google.

Не нужны или незаменимы

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

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

Вспомните пример с четырьмя реализациями push_back. Программисту, который не знал нашей мотивации — обеспечение гарантий безопасности, — будет совершенно неочевидно, почему мы обновили поле mem в начале функции, а не в другом месте. Ему покажется это прихотью, и он изменит способ на противоположный — просто для красоты кода. При этом корректная обработка исключений перестанет работать.

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

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

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

std::optional<PersonCard> ParseJSON(json raw_json, int idx) {
    PersonCard result;
    try {
        result.first_name = raw_json["persons"][idx]["name"]["first"].as_string();
        result.last_name = raw_json["persons"][idx]["name"]["last"].as_string();
        result.phone = parse_phone(raw_json["persons"][idx]["phone"].as_string());
        result.address = raw_json["persons"][idx]["address"];
    }
    catch(json::error e) {
        std::cout << "Error in JSON at " << e.where() << ": " << e.what() << std::endl;
        return std::nulltopt;
    }
    return result;
}

Без исключений только первая строка блока try записывалась бы так:

if (!raw_json.is_object()) return std::nullopt;
if (!raw_json.has_key("persons")) return std::nullopt;
if (!raw_json["persons"].is_array()) return std::nullopt;
if (raw_json["persons"].length() >= idx) return std::nullopt;
if (!raw_json["persons"][idx].is_object()) return std::nullopt;
if (!raw_json["persons"][idx].has_key("name")) return std::nullopt;
if (!raw_json["persons"][idx]["name"].is_object()) return std::nullopt;
if (!raw_json["persons"][idx]["name"].has_key("first")) return std::nullopt;
if (!raw_json["persons"][idx]["name"]["first"].is_string()) return std::nullopt;

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

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

Строгий запрет

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

Для GCC и clang это опция -fno-exceptions. Её использование не значит, что исключений не возникнет. В частности, никто не может избавить вас от std::bad_alloc и других исключений, выбрасываемых из библиотек. Однако чаще всего исключение будет приводить к вызову std::terminate.

Если на радикальные меры идти не хочется, ваш друг — noexcept. Он работает не хуже, чем -fno-exceptions, если его поставить везде, где нужно. noexcept также хорошо помогает оптимизатору и убирает оверхед при вызове функций, помеченных этим ключевым словом.

Назад в будущее

У исключений есть альтернатива, известная ещё корифеям, — возврат флага или ошибки из функции. Если вы пишете процедуру, то проще всего вернуть флаг успеха:

bool DoSomeOperation() {
    if (!CanDoOperation()) 
        return false;
    DoUnchecked();
    return true;
}

Чтобы компилятор проверял, что вызывающая функция точно обрабатывает ошибку, добавим [[nodiscard]]:

[[nodiscard]] bool DoSomeOperation() …

Подобного сервиса — проверки, что ошибка обрабатывается, — нет даже у исключений. Если булевого флага недостаточно, функция может возвращать объект ошибки, содержащий информацию о её причинах. В этом случае [[nodiscard]] можно поставить прямо в класс:

struct [[nodiscard]] ErrorInfo {
    // Операция вернёт false, если ошибки не было.
    operator bool() const {
        return error_code != 0;
    }

    std::string what() const;
    int error_code = 0;
}

ErrorInfo DoOperation();

int main() {
    auto err = DoOperation();
    if (err) {
        std::cout << err.what() << std::endl;
        return EXIT_FAILURE;
    }
}

Когда функция должна сама по себе вернуть значение, такой способ не подходит. Решение есть — специальный тип std::expected, но он будет добавлен в язык только в 2023 году. Предполагается, что этот объект будет хранить либо возвращённое значение, либо код ошибки, когда операция не удалась.

Универсальный солдат

Если ждать до 2023-го не хочется, можно реализовать expected самостоятельно или использовать простую замену: передать функции объект ошибки по ссылке, предлагая записать в него информацию.

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

std::filesystem. Функции работы с файловой системой часто могут завершаться с ошибкой. Например, вы хотите переименовать файл, но его только что удалили. В этом и подобных случаях выбрасывается std::filesystem::filesystem_error, подкласс std::system_error, который в свою очередь расширяет подкласс std::runtime_error и std::exception.
Но если вы указали дополнительный параметр типа std::error_code&, то исключение не будет выброшено — вместо этого ошибка запишется в переданный объект:
```
std::error_code ec;
std::filesystem::rename(old_path, new_path, ec);
if (!ec) {
    std::cerr << "Ошибка переименования" << std::endl;
}
```
Потоки ввода-вывода. Для них используется немного другой механизм. По умолчанию потоки не выбрасывают, и вы вынуждены проверять все операции на корректность.
Если вызвать метод потока exceptions, то можно попросить поток сигнализировать при появлении флагов ошибок. Будет выбрасываться исключение std::ios_base::failure (также подвид std::system_error). У метода есть эффект, даже если он вызван уже после возникновения ошибки:
```
#include <iostream> 
#include <fstream> 
 
int main()
{
    std::ifstream f("abracadabra");
 
    try {
        f.exceptions(f.failbit);
    }
    catch (const std::ios_base::failure& e) {
        std::cout << "Ошибка потока: " << e.what() << 'n'
                  << "Код: " << e.code() << 'n';
    }
}
```
Передавать в метод exceptions флаг eofbit не рекомендуется. Достижение конца файла — штатная, а не исключительная ситуация. Последующие чтения всё равно установят флаг fail.

А что со скоростью?

Бытует мнение, что исключения — это всегда медленно. Ведь у всех этих конструкций try наверняка большой оверхед. Даже если try-блоков нет, компилятор всё равно должен быть в любой момент готов обработать исключение при вызове любой функции, не помеченной как noexcept.

Проверим, так ли это. Лучший способ — бенчмарк. Будем измерять две функции, выполняющие похожую работу:

void f() — не помечена как noexcept. Рекурсивно вызывает себя. После 10 миллионов вызовов выбрасывает исключение.
bool g() — помечена как noexcept. Рекурсивно вызывает себя. После 10 миллионов вызовов возвращает false, и цепочка вызовов прерывается.

Результат во многом зависит от компилятора, оптимизаций и наличия у функций атрибута noinline. Но в большинстве случаев версия с исключениями по крайней мере не хуже. Вот бенчмарк, где версия с исключениями работает в полтора раза быстрее. При использовании clang преимущество скромнее — всего 10%.

Может показаться, что пример искусственный. В какой-то степени так и есть, но это не меняет тенденции. Без исключений в C++ нам нужно было проверять каждый результат возврата, а это дорогостоящая инструкция условного перехода. Трудно поверить, но при использовании исключений такая инструкция при вызове не требуется. Иногда это может дать неплохой выигрыш.

Сравним дизассемблер. Для наглядности добавим больше рекурсивных вызовов в каждую функцию. Так выглядит вариант с исключениями:

Каждый рекурсивный вызов превратился в одну инструкцию call, последний — в jmp

А вот начало функции с проверками. Не будем приводить код полностью:

Каждый рекурсивный вызов превратился в три инструкции — call, test и условный переход

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

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

Как работают исключения

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

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

Современные компиляторы (а вернее, генераторы кода) в полной мере этому принципу не следуют, в чём можно убедиться, изучив ассемблерный код, который они выдают. Но возникающий оверхед минимальный, а где-то отсутствует вовсе. Подумаем, что обязан делать процессор для того, чтобы обеспечить возможность исключений.

Посадочные площадки

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

std::string s = "Имя гостя номер " + std::to_string(N) + " - " + guest_names.at(N);
std::cout << s << std::endl;

Они могут прерваться в девяти местах:

два раза — при конвертации const char* в std::string; возможное исключение bad_alloc;
три раза — при сложении строк; возможное исключение bad_alloc;
один раз — в std::to_string; возможное исключение bad_alloc;
один раз — в std::vector::at; возможное исключение std::out_of_range;
два раза — в std::ostream::operator <<; возможное исключение std::ios_base::failure. Даже если мы не устанавливали для потока флаг выброса исключений, компилятор всё равно должен быть готов к такому повороту событий — операция << не помечена как noexcept.

Для этих девяти мест компилятор должен предусмотреть пути отхода. А именно установить, какие временные объекты он должен удалить в каждом случае и что делать дальше. Для этого в бинарном коде программы создаётся посадочная площадка (landing pad). Процессор приземляется на ней только в случае исключения.

Вызов функции обычно превращается в процессорную инструкцию call. При этом в стек кладётся адрес места, куда нужно вернуться после инструкции ret, завершающей вызов. Если вызываемая функция помечена как noexcept, то этого достаточно. Если нет, процессору нужно знать, куда идти, если в процессе выполнения вызова произошло непойманное исключение. Он идёт на посадочную площадку.

Таким образом для возможности обработки исключений каждый вызов требует максимум одну дополнительную инструкцию — запоминание адреса экстренной посадочной площадки. Сущая мелочь.

Выбор обработчика

Мы так увлеклись оверхедом, что совсем забыли: исключения нужны, чтобы их ловить. А ловят их обработчики. Чтобы исключение нашло свой обработчик, при выполнении raise нужно сохранить информацию о типе. Причём эта информация будет обрабатываться во время выполнения программы (run-time).

В C++ для этого есть свой механизм — динамическая идентификация типа данных, или RTTI. Чтобы мы могли поймать исключение по базовому типу, в run-time должна быть доступна информация обо всех предках выброшенного исключения.

Таким образом, raise делает следующее:

сохраняет объект исключения;
сохраняет информацию о типе;
возможно, сохраняет что-то ещё (например, ссылку на деструктор объекта исключения);
если надо, запускает terminate;
если не надо, запускает раскрутку стека.

Раскрутка стека делает следующее:

приземляется на посадочную площадку;
удаляет временные и автоматические объекты;
проверяет все доступные обработчики на соответствие типа;
если надо, запускает terminate;
если не надо (и обработчик не найден), продолжает раскрутку стека.

Обработчик делает следующее:

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

И снова бенчмарк

Чтобы проверить, что информация о типе действительно обрабатывается в run-time, проведём ещё один любопытный бенчмарк. Создадим тип F очень простого вида:

struct F{};

А также шаблон template<int> struct G. Его особенность — в том, что у типа G<0> очень много потомков, 2048 штук. В функции f всё просто: будем бросать исключение типа F и затем ловить исключение типа F. В функции g будем бросать исключение типа G<0>, а ловить по типу одного из его многочисленных потомков — G<1111>.

Если наше предположение верно, то программе потребуется гораздо меньше времени для поиска обработчика исключения типа F. Напротив, чтобы убедиться, что обработчик типа G<1111> соответствует выброшенному исключению типа G<0>, придётся потрудиться.

Запустим бенчмарк и убедимся в своей правоте:

Слева обработка исключения типа G<0>, справа — типа F

Поимка объекта по глубокому производному классу заняла в 32 раза больше времени. Таким образом мы убедились, что проверка исключения на соответствие типу действительно происходит в run-time.

Мы рассмотрели подкапотную исключений и увидели, что часть важной работы происходит в run-time, что несвойственно для C++. Может быть, это даже не очень эффективно, но, как было сказано выше, при обработке исключений эффективность отодвигается на второй план. Ведь это исключительная ситуация, и в том, чтобы потратить несколько десятков тысяч лишних инструкций, нет ничего страшного.

Заключение

Мы проделали большую работу. Разобрались в тонкостях исключений в C++, гарантиях, спецификациях. Узнали, что, вопреки распространённому мнению, исключения — не всегда медленно.

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

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

Полезные ссылки

Курс «Разработчик C++» в Яндекс Практикуме
Дополнительный курс «C++ для бэкенда» в Яндекс Практикуме
Блок try в энциклопедии cppreference
Конструкция throw в энциклопедии cppreference
Спецификации исключений в энциклопедии cppreference
Стандартные типы исключений в энциклопедии cppreference
Доклад «Исключения C++ через призму компиляторных оптимизаций» на конференции C++ Russia 2019 Piter
Сервис микробенчмарков Quick C++ Benchmark
Раздел «Исключения» стайлгайда Google

Источник

О чём тут не будет: напоминания базовых конструкций языка и основных моментов о том, как с ними работать; подробного разбора, как работают исключения (писали тут и тут); как грамотно спроектировать ваш класс/программу, чтобы не наломать дров в будущем с гарантией исключений (разве что совсем чуть-чуть, хотя я сам и не очень-то тук-тук).

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

Текущее состояние дел

Перед тем, как посмотреть, что же есть в C++, давайте вспомним, как с ошибками жили C-программисты. Тут есть несколько опций:

возвращать код ошибки. Например заранее определить enum с возможными кодами ошибок:

enum err { OK = 0, UNEXPECTED };
err func(int x, int** result);

использовать thread-local значения вроде errno (для windows GetLastError):

передавать отдельную переменную для ошибки:

int* func(int x, err* errcode);

использовать setjmp/longjmp. В C++ стоит об этом категорически забыть (деструкторы и всё такое).

Почему этого недостаточно? Код возврата/параметр очень легко проигнорировать. Как часто вы проверяли, что вернули scanf/printf? Установку errno ещё легче.

Из-за этих (и ряда других) причин в С++ появились исключения. Их преимущества:

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

И недостатки:

flow кода может быть непредсказуем;
некоторый оверхед на поддержку исключений. Причём он есть, даже если вы исключения не используете (и не сделали что-то для того, чтобы его не было).

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

std::error_code ec { MY_ERRC, std::errc::not_enough_memory};
...
if (ec == std::errc::not_enough_memory) {…}

Спорить о том, что же удобнее и эффективнее, – не самое продуктивное занятие. В языке есть оба инструмента, которые нужно применять исходя из ваших нужд и требований (даже Bjarne Stroustrup писал, что исключения не замена другим возможным техникам обработки). Самый простой пример – исполнение в constexpr-контексте. При выполнении кода с бросанием исключений в constexpr-контексте вы получите ошибку компиляции (это даже как чит используется). Однако вы можете захотеть уметь в compile time обрабатывать ошибки. Тут вам и помогут коды возвратов. Только не std::error_code: эти ребята в constexpr не умеют.

Ещё, грубо говоря, std::optional тоже своего рода механизм обработки ошибок, но семантически его часто используют не для исключительных ситуаций, а для приемлемых ситуаций. Так что well yes but actually no.

Светлое будущее

Следующим шагом для стандартного C++ является пропозал по введению std::expected<T, E> (аналог Result<T, E> из Rust). Здесь возвращается либо результат, либо сконструированное исключение (или std::error_code, int, MyErrorClass и что угодно ещё). Есть хороший доклад Andrei Alexandrescu на CppCon2018 про это. Можно посмотреть вариант базовой реализации.

Всё новое хорошо забытое старое…

Вообще подобные штуки можно было делать и раньше, например с помощью std::exception_ptr, std::current_exception и std::rethrow_exception. Ловите ваше исключение и работаете с ним, как объектом, пока не нужно бросить его дальше. Но идея std::expected это всё-таки уровень повыше: у вас всегда пара значений, в которой есть только что-то одно.

Мне нравятся варианты с корутинами, если не обращать внимания на неприятные глазу приставки co_ к половине операторов. Например такой, где они совмещаются со std::expected и всё это варится в виде монад, что позволяет напрямую не обрабатывать ошибки без необходимости:

struct error {
  int code;
};

expected<int, error> f1() { return 7; }
expected<double, error> f2(int x) { return 2.0 * x; }
expected<int, error> f3(int x, double y) { return error{42}; }

auto test_expected_coroutine() {
  return []() -> expected<int, error> {
    auto x = co_await f1();
    auto y = co_await f2(x);
    auto z = co_await f3(x, y);
    co_return z;
  }();
}

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

Рядом с пропозалом о std::expected ещё есть пропозал об operator try() (что-то вроде operator ? из Rust), который помогает писать меньше кода. Автор предлагает ввести понятную конструкцию, чтобы не приходилось абузить корутины для достижения таких же результатов. Правда она в перспективе не дойдёт до стандарта до C++29.

Самой конфетой является предложение Herb Sutter про использование статических исключений. Пример из пропозала:

string f() throws {
  if (flip_a_coin()) throw arithmetic_error::something;
  return “xyzzy”s + “plover”; // any dynamic exception is translated to error
}

string g() throws { return f() + “plugh”; } // any dynamic exception is translated to error

int main() {
  try {
    auto result = g();
    cout << “success, result is: ” << result;
  }
  catch(error err) { // catch by value is fine
    cout << “failed, error is: ” << err.error();
  }
}

Появляется новое ключевое слово throws, которое означает, что функция возвращает на самом деле (грубо говоря) std::expected<T, error_code>, а все throw в функции — на самом деле return, который возвращает код ошибки. И теперь можно будет писать всегда либо throws, либо noexcept. Ещё тут предлагается расширить кейсы использования ключевого слова try: использовать вместе с/вместо return, при инициализации, использовать при передаче аргументов функций. Немного синтаксического сахара при использовании catch. А ещё предлагаемая модель является real-time safe (это когда время работы инструмента/механизма ограничено сверху известной величиной) в отличие от текущей реализации исключений. Однако работа над этим пропозалом не велась с 2019, и что с ним и как непонятно.

Как альтернатива есть статья James Renwick о другой реализации такого же механизма, как у Herb Sutter, но она подразумевает слом ABI, что почти наверняка в ближайшие годы не случится.

Набросы

Часто считается плохой практикой бросать что-то не унаследованное от стандартных ошибок. И тут (как и со своими типами) стоит быть аккуратным:

struct e1 : std::exception {};
struct e2 : std::exception {};
struct e3 : ex1, ex2 {};
int main() {
  try { throw_e3(); }
  catch(std::exception& e) {}
  catch(...) {}
}

Т.к. у e3 несколько предков std::exception => компилятор не сможет понять, к какому именно std::exception нужно привести объект e3, потому это исключение будет отловлено в catch(...). При виртуальном наследовании e1, e2 от std::exception всё работает как ожидается.

Знатные маслины можно ловить при бросании исключений откуда не надо. Например, у стандартной библиотеки есть некоторые инварианты, без которых написание кода стало бы ужасной мукой (а может и вовсе невозможным). Одним из них является предположение, что деструкторы, операции удаления и swap не бросают исключений, потому хорошо бы помечать их noexcept. Если по каким-то причинам внутри что-то может вылететь, на месте (прям до выхода из функции/методов) ловите исключения и пытайтесь исправить ситуацию, чтобы состояние программы осталось валидным. По-хорошему ещё и move-операции должны быть небросающими, т.к. это открывает путь к более эффективному коду (классический пример это использование std::move_if_noexcept в std::vector).

Собственно с деструкторами и начинается самый флекс: если исключение вылетает при раскрутке стека, вы сразу ловите std::terminate. Бороться с такими проблемами можно разными способами. Самый хороший – не бросать исключения из деструкторов. Если очень хочется, юзайте noexcept(false), но лучше отбросьте эти богохульные мысли и идите спать. Чуть больше про это можно почитать вот тут.

Интересные штуки ещё можно делать со статическими переменными. Во-первых, их инициализация происходит атомарно. Во-вторых, только один раз. Т.е. если вы хотите выполнить какой-то единожды, вы можете сделать следующее:

[[maybe_unused]] static bool unused = [] {
    std::cout << "printed once" << std::endl;
    return true;
 }();

А что, если хочется выполнить какой-то код ровно n раз? Тут можно воспользоваться фактом, что, если при инициализации вылетает исключение, переменная не инициализируется и попытается инициализироваться в следующий раз:

struct Throwed {};
constexpr int n = 3;

void init() {
  try {
    [[maybe_unused]] static bool unused = [] {
      static int called = 0;
      std::cout << "123" << std::endl;
      if (++called < n) {
        throw Throwed{};
      }
      return true;
    }();
  } catch (Throwed) {}
}

Но это тоже говнокод ¯_(ツ)_/¯.

Какие-то рекомендации

Набросы из личного опыта и советов из интернетов, которые, к сожалению, получилось прочувствовать на себе:

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

Если для ситуации RAII подходит недостаточно (нужно совершить не очистку ресурсов, а просто набор действий), сообразите что-то вроде gsl::finally.
Используйте исключения, если в конструкторе объекта становится понятно, что объект создать невозможно (раз, два). Тут так-то других вариантов особо и нет: возвращаемое значение у конструкторов не предусмотрено. Можно конечно завести условный метод IsValid и обмазаться конструкциями с if, но имхо не оч удобно.
Можно использовать исключения для проверки пред-/постусловий.
В силу непредсказуемости flow выполнения вашего кода из-за исключений, можно с ними знатные приколы мутить. Встречались кейсы, когда исключения использовались для выхода из глубокой рекурсии, нескольких циклов сразу или, внезапно, даже возврата значения из функции. Не делайте так. Исключения они на то и исключения, чтобы детектить ошибки. Exceptions are for exceptional.
Но не переусердствуйте с ловлей исключений. Хорошо, когда вы ожидаете какую-то конкретную ошибку и ловите именно её. Думаю, вы тоже видели код с конструкциями вида catch (...) {}, потому что “ну там какие-то исключения вылетают, а падать не хочется”. Разберитесь с этим и контролируйте (может у вас есть действительно хорошие примеры, где это наилучшее решение; тогда расскажите в комментариях).
Если не можете обработать исключение, делайте аборт (std::abort/std::terminate/std::exit/std::quick_exit).
Старайтесь ловить исключения так, чтобы они копировались минимальное количество раз (с помощью ссылок/указателей/exception_ptr). В идеале ноль.

Ещё немного набросов

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

Если вы точно не хотите использовать исключения, можно компилировать ваш проект с -fno-exceptions, что позволяет не поддерживать исключения при компиляции -> открыть возможности для новых оптимизаций (будьте готовы к разным неожиданным эффектам; например стандартная библиотека станет падать там, где раньше вылетали исключения).

Вы можете использовать function-try-block для ловли исключений из всей функции/конструкторов со списками инициализации:

struct S {
  MyClass x;

  S(MyClass& x) try : x(x) {
  } catch (MyClassInitializationException& ex) {...} 
};

Но имейте в виду некоторые возможные проблемы.

Мне нравится как принято работать с ошибками в Golang: вы словили её, добавили к сообщению какую-то информацию и бросили дальше, чтобы в итоге сообщение у ошибки получилось примерно такое: “topFunc: secondFunc: firstFunc: some error text”. Довольно удобно (по крайней мере в Go), если у вас похожая парадигма работы с ошибками и нет stacktrace рядом с исключениями. Однако в C++ стоит быть осторожным, потому что есть механизм std::throw_with_nested, который совсем о другом. Концептуально тут всё просто: у исключений может быть вложенное исключение, которое можно достать из родительского исключения. Получается, можно сделать дерево в виде цепочки из исключений (прямо как в Java есть cause у исключений, но там этот механизм чуть шире и делать так принято). Имхо если вы такое используете, у вас какие-то архитектурные проблемы, так что перед написанием новых велосипедов, задумайтесь, всё ли в порядке.

Бесполезный (но забавный) факт. Вот такой код вполне себе корректен: throw nothrow.

Несмешная нешутка.

*шутка про то, что C++ – ошибка, которую не сумели правильно обработать*

Реклама.

Можете подписаться на канал о C++ и программировании в целом в тг: t.me/thisnotes.

Источник

Определено в заголовке `<filesystem>`
class filesystem_error;		(since C++17)

Класс std::filesystem::filesystem_error определяет объект исключения, который генерируется при сбое из-за перегрузки функций в библиотеке файловой системы.

Member functions

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

Наследуется от std :: system_error

Member functions

	код ошибки возврата (открытая функция-член `std::system_error` )
[virtual]	возвращает пояснительную строку (виртуальная общедоступная функция-член `std::system_error` )

Унаследовано от std::runtime_error

Наследуется от std :: exception

Member functions

[virtual]	уничтожает объект исключения (виртуальная публичная функция-член `std::exception` )
[virtual]	возвращает пояснительную строку (виртуальная публичная функция-член `std::exception` )

Notes

Чтобы гарантировать, что функции копирования filesystem_error системы_ошибки не являются исключением, типичные реализации хранят объект, содержащий возвращаемое значение what() , и два объекта std::filesystem::path , на которые ссылаются path1() и path2() соответственно, в отдельно выделенном хранилище с подсчетом ссылок.

В настоящее время реализация MS STL не соответствует требованиям: упомянутые выше объекты хранятся непосредственно в объекте filesystem , что делает функции копирования не нулевыми.

Example

#include <system_error>
#include <filesystem>
#include <iostream>
 
int main()
{
    const std::filesystem::path from{"/nonexistent1/a"}, to{"/nonexistent2/b"};
    try {
        std::filesystem::copy_file(from, to); 
    }
    catch(std::filesystem::filesystem_error const& ex) {
        std::cout
            << "what():  " << ex.what() << 'n'
            << "path1(): " << ex.path1() << 'n'
            << "path2(): " << ex.path2() << 'n'
            << "code().value():    " << ex.code().value() << 'n'
            << "code().message():  " << ex.code().message() << 'n'
            << "code().category(): " << ex.code().category().name() << 'n';
    }
 
    
    std::error_code ec;
    std::filesystem::copy_file(from, to, ec); 
    std::cout << "nnon-throwing form sets error_code: " << ec.message() << 'n';
}

Possible output:

what():  filesystem error: cannot copy file: No such file or directory [/nonexistent1/a] [/nonexistent2/b]
path1(): "/nonexistent1/a"
path2(): "/nonexistent2/b"
code().value():    2
code().message():  No such file or directory
code().category(): generic
 
non-throwing form sets error_code: No such file or directory

C++

std::filesystem::file_time_type

Представляет время файла.
std::filesystem::file_type

file_type определяет константы,указывающие путь к каталогу или директории,к которой относится Возможный вывод:
std::filesystem::filesystem_error::filesystem_error

Создает новый объект filesystem_error.
std::filesystem::filesystem_error::operator=

Присваивает содержимое с содержимым других.

Источник

Содержание

C++ — Урок 011. Исключения
Инварианты
Виды исключений
std::logic_error
std::invalid_argument
std::domain_error
std::length_error
std::out_of_range
std::future_error
std::runtime_error
std::range_error
std::overflow_error
std::underflow_error
std::system_error
std::ios_base::failure
std::bad_typeid
std::bad_cast
std::bad_weak_ptr
std::bad_function_call
std::bad_alloc
std::bad_array_new_length
std::bad_exception
20.5 – Исключения, классы и наследование
Исключения и функции-члены
Когда конструкторы дают сбой
Классы исключений
Исключения и наследование
std::exception
Использование стандартных исключений напрямую
Создание собственных классов, производных от std::exception или std::runtime_error

C++ — Урок 011. Исключения

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

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

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

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

Здесь применяется исключение out_of_range. Данное исключение определено в заголовочном файле .

Оператор throw передаёт контроль обработчику для исключений типа out_of_range в некоторой функции, которая прямо или косвенно вызывает Vector::operator . Для того, чтобы обработать исключения необходимо воспользоваться блоком операторов try catch.

Инварианты

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

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

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

Если в качестве аргумента size будет передано отрицательное значение
Если оператор new не сможет выделить память

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

Обработка исключений будет выглядеть следующим образом:

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

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

Все исключения стандартной библиотеки наследуются от 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)