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

Ну вот кстати себе я таки на сях ;) сделал специфичный fail fast такого плана. Но он втыкает уникальный код факапа в глобальную переменную. Он один на весь исходник - и вот так место факапа известно с точностью до.

Но это юзается там где оно уместно. Если я посчитаю что такая реакция на ошибки в проекте уместна. Ну скажем фирмварь микроконтроллера - в определенных допущениях - может быть быстро целиком ребутнута, может быть даже с восстановлением state той или иной полноты, если анализ системы показал что так рекавери выглядит безопасно. Однако микроконтроллер, видите ли, теряет контроль при этом на жалкие микросекунды, state маленький, а перспектива глюкать дофига времени с потенциально порушенным state программы и/или железа (fail fast ловит грубо говоря "sanity check failed"). Из очевидных плюсов - caller'ы умеют забивать на проверку ошибок в кодах возврата, а сами коды часто конфликтуют с полезными значениями. Поэтому как _один из_ вариантов почему бы и нет? Однако сие годится не всегда и не везде. Если не годится, оно даунгрейдится до проверок на манер errno. Лишних кейвордов при этом не надо. Си вообще приколен там что сам по себе - мультипарадигменный. Он настолько простой и дубовый что в принципе из него лепится любая парадигма с минимальной интерференцией. А хруст, вот, показал себя в этом заметно хуже пока, подпихав дурацкие медвежьи услуги где не надо.