0xCOFFEEЕсли дальше думать , то надо к этому ещё ввести состояние, которое позволит в неопределенных местах перехватывать критические ошибки перед падением, делать перегрузку и возвращать в его Стейт с данными что были на тот момент , перед перегрузкой надо сохранять состояние, ну и на стартовой исходящей п
Оверхед
0 Для крупных приложений и Энтерпрайз это как раз правильное решение ) плюс так бы действовали к примеру в финтек с платежными решениями, только там бы не сохранялось состояние а полная перегрузка, если была операция фина, после перегрузки команда реверс на процессинг, пока 200 не пришло слать в сервисе команду реверса) то что кажется оверхед может казаться в очень маленьком приложение и не финансово ответственным или жизненно не ответственного , то да. Но если сли приложение связано с деньгами, жизнью это обязано быть
0xCOFFEEТут либо все покрывать тру кейч и в стандартном стиле ООП, либо реализация реактивной архитектуры, где состояние цепей функций выполнения по результату успеха либо ошибки возвращается в место вызова + позволяет управлять многопоточностью и асинхронностью (спойлер я бы выбрал реактивный вариант) но т
Метод main в тру кач оберни и все)))