Здравствуйте, 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).
Альтернативные варианты подробно описывал тут

Автор: Evgeny.Panasyuk
Дата: 17.11.15

и тут

Автор: Evgeny.Panasyuk
Дата: 27.09.12

.

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