На этом форуме была уже не одна дискуссия на тему преимуществ и недостатков исключений. Желающие могут легко глянуть поиском. И я уже отмечался в них, в основном с негативным взглядом на данную технику. Точнее я вижу в ней только инструмент обработки реально критических ошибок (типа нехватки памяти и т.п.), приводящих всегда к аварийному завершению приложения (один глобальный try/catch). Тут они конечно хороши. Если же использовать исключения для банального возвращения неудач из функций, то в итоге это становится даже менее удобно чем древние коды возврата (особенно если в языке реализована удобная работа с кортежами и типами реализующими концепцию монады maybe), из-за непрерывных убогих try/catch на каждом углу.
Я эту мысль уже высказывал раньше и моё мнение в общем то не изменилось. Но недавно я наткнулся на обсуждение выступления Александреску (http://habrahabr.ru/post/270545/ там же есть ссылка на само выступление) на близкую тему и увидел вариант реально удобного повсеместного использования исключений. Кстати, там тоже в начале высказываются мысли о неудобности классического подхода исключений, созвучные с моей позицией.
В общем если использовать такой подход, то исключения становятся уже реально удобным инструментом для построения логики приложения. Только вот это должно применяться системно, т.е. везде в приложение, а не эпизодическими моментами. )))
Здравствуйте, alex_public, Вы писали:
_>то в итоге это становится даже менее удобно чем древние коды возврата (особенно если в языке реализована удобная работа с кортежами и типами реализующими концепцию монады maybe), из-за непрерывных убогих try/catch на каждом углу.
Не припомню чтобы кто-то из сторонников исключений выступал за использование "try/catch на каждом углу".
_>Кстати, там тоже в начале высказываются мысли о неудобности классического подхода исключений, созвучные с моей позицией.
Подобное неудобство было бы и при кодах возврата. Да и вообще, там не "про неудобство классического подхода" в целом, а лишь о нескольких конкретных use-case'ах, которые разгуливаются несколькими дополнениями в язык, которые кардинально не меняют "классический подход", а лишь дополняют его в нескольких случаях.
P.S. Я думал что ты говоришь про его выступление об expected<T> — это ближе к сабжу, нежели scope(exit/success/failure)
Здравствуйте, alex_public, Вы писали:
_>Я эту мысль уже высказывал раньше и моё мнение в общем то не изменилось. Но недавно я наткнулся на обсуждение выступления Александреску (http://habrahabr.ru/post/270545/ там же есть ссылка на само выступление) на близкую тему и увидел вариант реально удобного повсеместного использования исключений. Кстати, там тоже в начале высказываются мысли о неудобности классического подхода исключений, созвучные с моей позицией.
Гхм... может я чего-то не улавливаю? По-моему это абсолютно стандартный finally, только на макросах и с вариациями для fault и success clauses (последняя по-моему добавлена "чтоббыло", ну да фиг с ним).
Здравствуйте, Sinix, Вы писали:
S>Гхм... может я чего-то не улавливаю? По-моему это абсолютно стандартный finally, только на макросах и с вариациями для fault
Это всё же не вариация finally. В одном из предыдущих выступлений есть наглядный пример (link — первые полчаса).
Основная фишка в простой линейной композиции без необходимости углублять scopes.
На try/catch/finally же будет несколько уровней вложенности, с более сложной структурой кода.
Но, опять-таки, это лишь дополнение для некоторых случаев, а не другой подход.
S>и success clauses (последняя по-моему добавлена "чтоббыло", ну да фиг с ним).
Он в одном из выступлений так и говорит — что scope(success) требуется реже.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
_>>то в итоге это становится даже менее удобно чем древние коды возврата (особенно если в языке реализована удобная работа с кортежами и типами реализующими концепцию монады maybe), из-за непрерывных убогих try/catch на каждом углу. EP>Не припомню чтобы кто-то из сторонников исключений выступал за использование "try/catch на каждом углу".
А оно автоматом возникает в случае применения исключений не только для критических сбоев. Потому как в таком случае обработка ошибки происходит не где-то на высоком уровне, а почти всегда на уровне вызова функции, кидающей исключения. В предыдущих темах я уже приводил примеры на эту тему.
EP>Подобное неудобство было бы и при кодах возврата. Да и вообще, там не "про неудобство классического подхода" в целом, а лишь о нескольких конкретных use-case'ах, которые разгуливаются несколькими дополнениями в язык, которые кардинально не меняют "классический подход", а лишь дополняют его в нескольких случаях.
Дело в том, что при применение исключений везде, этот случай становится как раз самым распространённым. Вот к примеру ошибка при невозможности сохранить файл — она должна обрабатываться с помощью исключений или же нет? ) И если с помощью исключений, то каким подходом лучше? )
EP>P.S. Я думал что ты говоришь про его выступление об expected<T> — это ближе к сабжу, нежели scope(exit/success/failure)
Здравствуйте, Sinix, Вы писали:
_>>Я эту мысль уже высказывал раньше и моё мнение в общем то не изменилось. Но недавно я наткнулся на обсуждение выступления Александреску (http://habrahabr.ru/post/270545/ там же есть ссылка на само выступление) на близкую тему и увидел вариант реально удобного повсеместного использования исключений. Кстати, там тоже в начале высказываются мысли о неудобности классического подхода исключений, созвучные с моей позицией. S>Гхм... может я чего-то не улавливаю? По-моему это абсолютно стандартный finally, только на макросах и с вариациями для fault и success clauses (последняя по-моему добавлена "чтоббыло", ну да фиг с ним).
Здравствуйте, alex_public, Вы писали:
EP>>P.S. Я думал что ты говоришь про его выступление об expected<T> — это ближе к сабжу, нежели scope(exit/success/failure) _>Тут скорее уж optional актуальнее. )
Почему? expected<T> это считай variant<T, exception_ptr>, как раз позволяет передать конкретную информацию об ошибке.
Вот выступление.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>P.S. Я думал что ты говоришь про его выступление об expected<T> — это ближе к сабжу, нежели scope(exit/success/failure) _>>Тут скорее уж optional актуальнее. ) EP>Почему? expected<T> это считай variant<T, exception_ptr>, как раз позволяет передать конкретную информацию об ошибке. EP>Вот выступление.
Так в том то и дело, что expected<T> — это как раз полный аналог классических исключений. В то время как на практике чаще нужен именно optional<T> (или вообще просто bool). Я на эту тему уже когда-то давно здесь писал (например это http://rsdn.ru/forum/cpp/4623107
Здравствуйте, alex_public, Вы писали:
_>Я эту мысль уже высказывал раньше и моё мнение в общем то не изменилось.
У нас есть 2 возможных случая
Кейс 1. обработка ошибок находится на N уровней выше и ты даже не знаешь, а есть ли она. Это исключения, фактически способ передать управление на место обработки.
Кейс 2. обработка ошибок находится ровно на один уровень выше и ты всегда знаешь, что это так. Это коды ошибок, как правило низкоуровневый код.
По твоей ссылке изобретается известный способ использования конструкторов-деструкторов, т.к. любое исключение вызовет раскрутку стека.
Такой способ был изобретён еще в 90х, только тогда не было нормальных шаблонов и нужно было совершать бОльше телодвижений.
Про кейс 1, который убер основной, ты не сказал ничего внятного ни тогда, ни сейчас
Здравствуйте, Ikemefula, Вы писали:
I>У нас есть 2 возможных случая I>Кейс 1. обработка ошибок находится на N уровней выше и ты даже не знаешь, а есть ли она. Это исключения, фактически способ передать управление на место обработки. I>Кейс 2. обработка ошибок находится ровно на один уровень выше и ты всегда знаешь, что это так. Это коды ошибок, как правило низкоуровневый код.
I>По твоей ссылке изобретается известный способ использования конструкторов-деструкторов, т.к. любое исключение вызовет раскрутку стека. I>Такой способ был изобретён еще в 90х, только тогда не было нормальных шаблонов и нужно было совершать бОльше телодвижений.
Просто деструкторы — это по сути некий аналог finally, который не является чем-то особо интересным (тот же scope_exit есть в Бусте чуть ли не с рождения, но повсеместного его применения что-то не видно). А вот возможность понять чем вызван запуск деструктора (раскруткой стека исключением или же штатным выходом) даёт совершенно другие возможности, как раз являющиеся заменой уже catch.
I>Про кейс 1, который убер основной, ты не сказал ничего внятного ни тогда, ни сейчас
Про этот случай (это вариант обработки критических сбоев, обрабатываемый одним глобальным try/catch на приложение, ну или на поток) я как раз чётко написал, что тут классические исключения являются оптимальным инструментом. Однако в случае применения исключений не только для критических сбоев, но и для обработки логики, данный случае будет составлять жалкую долю от всей обработки ошибок в приложение.
Здравствуйте, alex_public, Вы писали:
_>Просто деструкторы — это по сути некий аналог finally, который не является чем-то особо интересным (тот же scope_exit есть в Бусте чуть ли не с рождения, но повсеместного его применения что-то не видно).
finally это очень интересно, а вот деструкторы — так себе. Например, потому что могут вызвать terminate
>А вот возможность понять чем вызван запуск деструктора (раскруткой стека исключением или же штатным выходом) даёт совершенно другие возможности, как раз являющиеся заменой уже catch.
Нету такой возможности.
I>>Про кейс 1, который убер основной, ты не сказал ничего внятного ни тогда, ни сейчас
_>Про этот случай (это вариант обработки критических сбоев, обрабатываемый одним глобальным try/catch на приложение, ну или на поток)
OMG !
1 На поток у нас и так есть uncaught хандлер и ничего специального обычно не нужно
2 Глобальный ровно ничего не даёт —
а из за потоков
б из за эвентлупа — реально приложение обрабатывает сообщения.
Все предельно просто — ты не знаешь есть у тебя обработчик выше или нет, решение ровно одно — throw.
Где ты обработаешь — решает вызывающий код. Фактически это разница между исключениями и кодами возврата есть в некотором смысле инверсия управления — не ты передаёшь управление, а у тебя его перехватывают.
Вопрос в том, где у тебя catch. catch всегда находится там, где есть 100% возможностей обработать ошибку.
Например некоторая операция с глубоким стеком сфейлилась.
варианты обработки
1. запрос юзера — retry, cancel
2. игнор результата всей операции
3. отложить операцию напозжа
4. игнор промежуточного результат
5. восстановить
...
N. дополняем информацию об ошибке и/или пробрасываем дальше
Итого, где может быть catch реально
1. публичный метод компонента — пробросить уточненное/скорректированое исключение
Пример — компонент mailClient. метод attach бросает вагон исключений, как то UnableEncode, UnableLocate, UnableRead, AccessDenied, NotAuthorizedUsingAttachments.
Что интересно, readFile и подобные вещи может и не использовать никаких исключений, а может использовать, но совершенно друие типы.
2. топовый хандлер некоторого _слоя_
Пример — OnSendMailButtonClick
3. обработка аппаратных или системных исключений.
Например страница памяти еще не подмаплена, это еще не повод выходить из приложения. Вместо этого подмапливаем нужную страницу и продолжаем с того места, где произошло исключение
4. упрощение логики
например в длинных вычислениях произошло деление на ноль. нас все устраиват, надо только результат выдать какой нибудь дефолтный в текстбоксе — Not a Number и тд.
5. в любом месте кода, что бы принять исключение с неизвестный глубины
примеры — с целью логировать, повторить, отложить, дополнить, игнорировать и тд, см выше
6 Самая 'нижняя' функция некоторого слоя — если нижележащий слой ведет себя непойми как.
Например System.Drawing в норме бросает OutOfMemory когда просто не может отрисовать слишком мелкий объект. OutOfMemory пудозреваю это ошибка маппинга где то в нативном коде, потому и проходит мимо имеющихся try catch
Здравствуйте, Ikemefula, Вы писали:
_>>Просто деструкторы — это по сути некий аналог finally, который не является чем-то особо интересным (тот же scope_exit есть в Бусте чуть ли не с рождения, но повсеместного его применения что-то не видно). I>finally это очень интересно, а вот деструкторы — так себе. Например, потому что могут вызвать terminate
Как раз scope_exit гораздо удобнее finally — Евгений уже показал это в сообщение выше.
>>А вот возможность понять чем вызван запуск деструктора (раскруткой стека исключением или же штатным выходом) даёт совершенно другие возможности, как раз являющиеся заменой уже catch. I>Нету такой возможности.
А данная возможность как раз продемонстрирована по ссылке в первом сообщение темы. )))
I>OMG ! I>...
Что-то ты понаписал кучу всего, включая какую-то свою личную классификацию ситуаций. А пользы от этого ноль. На самом деле на практике существует ровно две известных практики применения исключений (ну если не считать варианта их запрета, как в гугловских гайдах):
1. Применение исключений для обработки реально критических ситуаций. В этом случае существует один специальный обработчик, который обычно выдаёт сообщение об ошибке (возможно с какими-то опциями, типа сохранения отладочной информации и т.п.) и аварийно завершает приложение. С таким применением исключений согласны очень многие и я в том числе.
2. Применение исключений и для обработки критических ошибок и для обработки банальных неудачных вызовов. С таким применением согласны уже далеко не все. И вот лично мне он тоже не особо нравится. Потому что на мой вкус код вида (схематичный пример):
void OnSaveButton()
{
if(!SaveDocument()) MessageBox("Не могу сохранить документ");
}
гораздо удобнее и нагляднее чем
void OnSaveButton()
{
try{
SaveDocument();
}catch(exception&){
MessageBox("Не могу сохранить документ");
}
}
Так вот моя мысль в данной теме была в том, что если применить для второго варианта исключения в формате описанном в той статье, т.е. что-то вроде
void OnSaveButton()
{
SCOPE_FAIL{ MessageBox("Не могу сохранить документ"); };
SaveDocument();
}
то это будет уже не такой уж и плохой вариант для большинства случаев (если не критично быстройдействие, т.к. исключения всё же заметно тормозные). Конечно на таких простых примерах это не так уж и видно, однако если спроектировать это на случай более сложных функций со множеством условий, то преимущества должны быть очевидны.
Здравствуйте, alex_public, Вы писали:
_>На этом форуме была уже не одна дискуссия на тему преимуществ и недостатков исключений. Желающие могут легко глянуть поиском. И я уже отмечался в них, в основном с негативным взглядом на данную технику. Точнее я вижу в ней только инструмент обработки реально критических ошибок (типа нехватки памяти и т.п.)
ну ты блин философ.
OutOfMemException — это идин из тех трех гадов, после катча которых процесс уже не спасти ни чем.
плиз иксплейн свою мысль.
P.S. Кстати, а если в Catch(OutOfMemoryException) написать
{
new ManualResetEvent(false).WaitOne();
}
выживет ли процесс?
Кто пробовал?
P.P.S. я пробовал только что. процесс не мрёт, даже если не повесить поток в катч(OutOfMemoryException). разве так и должно быть?
Здравствуйте, alex_public, Вы писали:
_>>>то в итоге это становится даже менее удобно чем древние коды возврата (особенно если в языке реализована удобная работа с кортежами и типами реализующими концепцию монады maybe), из-за непрерывных убогих try/catch на каждом углу. EP>>Не припомню чтобы кто-то из сторонников исключений выступал за использование "try/catch на каждом углу". _>А оно автоматом возникает в случае применения исключений не только для критических сбоев. Потому как в таком случае обработка ошибки происходит не где-то на высоком уровне, а почти всегда на уровне вызова функции, кидающей исключения. В предыдущих темах я уже приводил примеры на эту тему.
Я об этом и говорю, не припомню чтобы сторонники исключений агитировали за использование их в тех случаях, где обработка происходит на том же уровне.
Есть конечно неоднозначные случаи, где аргументация сильна и за тот и за другой вариант (в смысле исключения или return code) — но это всё же редкость. И тут, кстати, частично помогает expected<T> и аналоги.
EP>>Подобное неудобство было бы и при кодах возврата. Да и вообще, там не "про неудобство классического подхода" в целом, а лишь о нескольких конкретных use-case'ах, которые разгуливаются несколькими дополнениями в язык, которые кардинально не меняют "классический подход", а лишь дополняют его в нескольких случаях. _>Дело в том, что при применение исключений везде, этот случай становится как раз самым распространённым.
Какой? scope(failure/success)? Посмотри например как часто они применяются в библиотеке D Phobos и в каких контекстах — то есть там где они присутствуют из коробки.
_>Вот к примеру ошибка при невозможности сохранить файл
Файл это не самый распространённый случай. Самый распространённый это выделение памяти, причём deallocate не фейлится.
_>- она должна обрабатываться с помощью исключений или же нет? )
Зависит от контекста.
_>И если с помощью исключений, то каким подходом лучше? )
Самый ванильный это ручное проставление .flush_may_throw() в конце scope (отдалённо напоминающее scope guard).
Альтернативные варианты подробно описывал тут
Здравствуйте, VladCore, Вы писали:
_>>На этом форуме была уже не одна дискуссия на тему преимуществ и недостатков исключений. Желающие могут легко глянуть поиском. И я уже отмечался в них, в основном с негативным взглядом на данную технику. Точнее я вижу в ней только инструмент обработки реально критических ошибок (типа нехватки памяти и т.п.) VC>ну ты блин философ. VC>OutOfMemException — это идин из тех трех гадов, после катча которых процесс уже не спасти ни чем.
Здравствуйте, alex_public, Вы писали:
_>Как раз scope_exit гораздо удобнее finally — Евгений уже показал это в сообщение выше.
Да, для ненужных кейсов удобнее, линейная композиция и все такое.
>>>А вот возможность понять чем вызван запуск деструктора (раскруткой стека исключением или же штатным выходом) даёт совершенно другие возможности, как раз являющиеся заменой уже catch. I>>Нету такой возможности.
_>А данная возможность как раз продемонстрирована по ссылке в первом сообщение темы. )))
Если ты в деструкторе вызываешь какую то логику, то надо ждать и исключения. Опаньки !
_>Что-то ты понаписал кучу всего, включая какую-то свою личную классификацию ситуаций. А пользы от этого ноль.
Это просто примеры. Что характерно, ты их ниасилил, подозреваю, просто не читал
>На самом деле на практике существует ровно две известных практики применения исключений:
Вообще то кроме 'практик' есть следующее
1 обработка ошибок
2 распространение ошибок — ты уже в который раз эту часть игнорируешь и не даёшь ответа, как же эту часть реализовать
_>2. Применение исключений и для обработки критических ошибок и для обработки банальных неудачных вызовов. С таким применением согласны уже далеко не все. И вот лично мне он тоже не особо нравится. Потому что на мой вкус код вида (схематичный пример):
_>
_>void OnSaveButton()
_>{
_> if(!SaveDocument()) MessageBox("Не могу сохранить документ");
_>}
_>
А ты понимаешь, что все зависит от реализации SaveDocument ?
Типичный SaveDocument это очень длинная операция и имеет глубокий стек вызовов. Например потому, что у нас там скорее всего работает врайтер-форматтер который по сути своей или рекурсивен, например (обход графа-дерева и тд и тд) или имеет слоёную структуру.
И вот где то глубоко-глубоко произошло исключение. Опаньки ! Как доставить на самый верх ?
Вобщем пример в студию !
_>Так вот моя мысль в данной теме была в том, что если применить для второго варианта исключения в формате описанном в той статье, т.е. что-то вроде _>
_>void OnSaveButton()
_>{
_> SCOPE_FAIL{ MessageBox("Не могу сохранить документ"); };
_> SaveDocument();
_>}
_>
_>то это будет уже не такой уж и плохой вариант для большинства случаев
1 что будет, если код, там где вызов MessageBox бросит исключение ?
2 как переписать на скопы такой пример:
Expression resultFromString(String str) {
try {
Expression expression = new Expression(str);
// считаем долго и рекурсивно
return Expression.Transform(expression.calculate(), Expression.Type('Miles'));
} catch(CalculationFailure ex) {
return Expression.NotANumber;
}
}
Здравствуйте, Evgeny.Panasyuk, Вы писали:
_>>А оно автоматом возникает в случае применения исключений не только для критических сбоев. Потому как в таком случае обработка ошибки происходит не где-то на высоком уровне, а почти всегда на уровне вызова функции, кидающей исключения. В предыдущих темах я уже приводил примеры на эту тему. EP>Я об этом и говорю, не припомню чтобы сторонники исключений агитировали за использование их в тех случаях, где обработка происходит на том же уровне. EP>Есть конечно неоднозначные случаи, где аргументация сильна и за тот и за другой вариант (в смысле исключения или return code) — но это всё же редкость. И тут, кстати, частично помогает expected<T> и аналоги.
Ты то может и не агитировал, но сторонников подхода "вся обработка ошибок через исключения" на этом форуме предостаточно.
_>>И если с помощью исключений, то каким подходом лучше? ) EP>Самый ванильный это ручное проставление .flush_may_throw() в конце scope (отдалённо напоминающее scope guard). EP>Альтернативные варианты подробно описывал тут
Здравствуйте, Ikemefula, Вы писали:
>>На самом деле на практике существует ровно две известных практики применения исключений: I>Вообще то кроме 'практик' есть следующее I>1 обработка ошибок I>2 распространение ошибок — ты уже в который раз эту часть игнорируешь и не даёшь ответа, как же эту часть реализовать
При использование исключений не для критических ошибок, а для обычной логики нет никакого распространения ошибок — всё обрабатывается на том же уровне. Максимум бывает перепаковка исключений (т.е. всё равно отлов на том же уровне), но это как раз вообще мрак с точки зрения удобства.
I>А ты понимаешь, что все зависит от реализации SaveDocument ? I>Типичный SaveDocument это очень длинная операция и имеет глубокий стек вызовов. Например потому, что у нас там скорее всего работает врайтер-форматтер который по сути своей или рекурсивен, например (обход графа-дерева и тд и тд) или имеет слоёную структуру. I>И вот где то глубоко-глубоко произошло исключение. Опаньки ! Как доставить на самый верх ? I>Вобщем пример в студию !
Тебе надо рассказать как вернуть булево значение из функции? )))
_>>Так вот моя мысль в данной теме была в том, что если применить для второго варианта исключения в формате описанном в той статье, т.е. что-то вроде _>>
_>>void OnSaveButton()
_>>{
_>> SCOPE_FAIL{ MessageBox("Не могу сохранить документ"); };
_>> SaveDocument();
_>>}
_>>
_>>то это будет уже не такой уж и плохой вариант для большинства случаев I>1 что будет, если код, там где вызов MessageBox бросит исключение ?
Ты видишь какую-то разницу в этом смысле с обычным подходом исключений? )))
I>2 как переписать на скопы такой пример: I>
Здравствуйте, alex_public, Вы писали:
>>>На самом деле на практике существует ровно две известных практики применения исключений: I>>Вообще то кроме 'практик' есть следующее I>>1 обработка ошибок I>>2 распространение ошибок — ты уже в который раз эту часть игнорируешь и не даёшь ответа, как же эту часть реализовать
_>При использование исключений не для критических ошибок, а для обычной логики нет никакого распространения ошибок — всё обрабатывается на том же уровне. Максимум бывает перепаковка исключений (т.е. всё равно отлов на том же уровне), но это как раз вообще мрак с точки зрения удобства.
Ты понимаешь, что мы говорим про случай, когда ошибка и обработка на разных уровнях ?
I>>Типичный SaveDocument это очень длинная операция и имеет глубокий стек вызовов. Например потому, что у нас там скорее всего работает врайтер-форматтер который по сути своей или рекурсивен, например (обход графа-дерева и тд и тд) или имеет слоёную структуру. I>>И вот где то глубоко-глубоко произошло исключение. Опаньки ! Как доставить на самый верх ? I>>Вобщем пример в студию !
_>Тебе надо рассказать как вернуть булево значение из функции? )))
Да, покажи вот для этого случая, в контексте SaveDocument: "где то глубоко-глубоко произошло..."
Простой кейс — XML-форматтер нашел случай, который не может зарезолвить, например циклические ссылки, форматтер обычный рекурсивный.
Покажи начиная с ошибки и заканчивая SaveDocument.
Здравствуйте, VladCore, Вы писали:
VC>OutOfMemException — это идин из тех трех гадов, после катча которых процесс уже не спасти ни чем.
ну что значит не спасти? надо просто перестать выделять память.
представьте что Вы пишете редактор картинок. юзер открывает один файл, второй, третий, тут раз — OOM. Показали юзеру сообщение "память закончилась, пожалуйста закройте другие файлы, перед тем как открывать новый", и всё, прога работает дальше
Здравствуйте, Abyx, Вы писали:
VC>>OutOfMemException — это идин из тех трех гадов, после катча которых процесс уже не спасти ни чем.
A>ну что значит не спасти? надо просто перестать выделять память. A>представьте что Вы пишете редактор картинок. юзер открывает один файл, второй, третий, тут раз — OOM. Показали юзеру сообщение "память закончилась, пожалуйста закройте другие файлы, перед тем как открывать новый", и всё, прога работает дальше
Если ты выделяешь память большими кусками, то это просто. А если мелкими и у тебя "где то посередине операции", то резко начинают "сыпаться" все консумеры, другие потоки например и тд.
