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

Вопрос №1:
Стоит ли в библиотечном коде при бросании исключения указывать и текстовку ошибки?

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

EvilsInterrupt, а теперь представь, что исключений в библиотеке 100 штук. Причем только 10 из них зависят от действий пользователя. Остальные 90 маловероятны. И ты будешь делать тексты для всех них? Если так, то ты мазохист.
Думаю, самый простой и портабельный способ - наследовать исключения от std::exception (или других его потомков, например: std::runtime_error) и сопровождать текстом. А в основном коде отлавливать ряд наиболее вероятных исключений и делать им локализацию. А остальным оставлять как есть.
Есть более корректный метод - сразу позаботиться о локализации (см. Qt, boost, gettext) внутри библиотеки.

>>Есть более корректный метод - сразу позаботиться о локализации (см. Qt, boost, gettext) внутри библиотеки. 
И привязаться к какой-либо системе локализации? Так сказать гвоздями вколотить ? )

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

Вопрос №2:
Как правильно откатить изменения, так сказать "транзакционность входных данных"?

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

Как из таких ситуаций выкручиваться?

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

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

bsa, 
>>Другое дело, аппаратный сбой. 
Да именно от таких, когда "никто не застрахован" и хочется "подстраховаться". Пока это на дилетантском уровне:

1) Используется лог-файл, все пишется в лог-файл
2) Если нет возможности использовать копию входных данных, то logger.debug() - сообщения пишутся в лог не зависимо от уровня логирования, даже если выставлен critical, info или error

EvilsInterrupt, если тебе необходима 100% надежность, то тогда используй копирование. Иначе, "забей" на аппаратные сбои.

Ок, переформулирую Вопрос №2 с учетом советов.

Вопрос №3:

Суть вопроса: Какие подходы существуют при обработке ошибок в приложениях с повышенными требованиями к надежности качеству?

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

Я понимаю, что  ответ на этот вопрос может занять книгу и т.д. Но почему-то уверен что основную и идею и принцип, так сказать brief можно вложить в абзац или в несколько абзацев. Интересует Используются ли бросание исключений в таких приложениях, что делается если обнаружена фатальная ошибка?

EvilsInterrupt, у меня профильное образование в переводе не русский язык звучит как "автоматизация ядерных реакторов". Так вот. В этих случаях используют уже несколько иные системы. Горячий, теплый и/или холодный резерв. А так же аварийные системы защиты (например, "ножницы" для отрезания тросов, поднимающих графитовые стержни, в случае сбоя автоматики).
Ну ты сам подумай, что будет делать твоя программа, если произойдет сгорание процессора, матери, винта, сбой ОС наконец или сегфолт в самой программе? Если у тебя идет управление жизненно важным объектом, то в этом случае от исключений следует вообще отказаться. А систему писать уже с расчетом на то, что будет аппаратный дублер (горячий или теплый резерв), причем не один.

Вопрос №4:

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

Пока нашел Паттерн Visitor для обработки иерархии исключений.

EvilsInterrupt, а может стоит как-то пересмотреть архитектуру? У тебя что, на каждое исключение своя уникальная реакция предполагается? Скорее всего нет.

bsa, 
Мои вопросы не связаны с каким-либо из моих проектов. Это вопросы понимание которых на уровне "каша в голове" ;) Связано с тем что пока при написании кода по обработке ошибок использую подходы "коды возврата" или "некорректное значение".

Возвращаясь к последнему вопросу №4:
>> а может стоит как-то пересмотреть архитектуру?
Мне не стоит. Мне  хочется понять, как писать код обработки ошибок использующий методику бросания исключений. Еще раз поясню что мне не понятно, возможно это пояснение будет более понятно:
В книге Страуструпа сказано, что бросать надо тогда, когда ВЫ обнаружили ошибку, но ничего в этом конкретном месте с нею сделать не можете. Также сказано, что ловит исключение тот, кто Может и знает как отреагировать на появление этой ошибки.
Из эти слов следует что вызывая в своем методе super_future() я не  могу знать точно, а сколько в нем вызывается методов и ф-ций. Вполне возможно что там произойдет вызов одной функции или вообще ни одной, но ведь может и 500 и больше! Как вывод, в любом месте вызванного кода может быть брошено исключение, на который мой метод может отреагировать и вдруг этих "может" 20 ситуаций с брошенными исключениями. Это что? Означает что я вынужден писать 20 catch блоков ?

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


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

Это сообщение отредактировал(а) drug007 - 16.1.2013, 13:35

Прошу прочитать еще раз! Если именно на данном уровне летит 20 исключений от нижестоящих уровней и которые я могу обработать? Надо ли мне в этом методе писать 20 catch-блоков?