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

А, вот откуда появлется куча "программистов", постоянно использующих паттерн:

let data; try

{

data = this.getSomeData(); } catch(error)

{ data = this.getErrorData();

console.error(error); }

this.doSomething(data);

Я с тобой согласен. Ме стоило добавить уточнение, когда такой паттерн действительно уместен. Например, при рискованных операциях на стороне браузера, которые могут выбросить ошибку — это браузерные API, которые пользователь может отключить, или ситуации с нехваткой времени или ресурсов, из-за чего вызов может завершиться с ошибкой (например, доступ к LocalStorage, запрос разрешения на камеру или микрофон). В таких случаях обработка через try/catch с запасным вариантом данных оправдана.
Я не вкладывал смысл в то, что его нужно использовать везде и всегда. Но там, где ошибка может возникнуть, но не может быть исправлена - он уместен (тот же пример с нехваткой памяти на стороне пользователя).

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

Подход с немедленной паникой при любой непредвиденной ошибке, безусловно, разумен. Но это совсем не про отказоустойчивость.
Мне кажется, что ты больше о стремлении писать код, о том как не допускать ошибки (допускать меньше). Это правильная цель — и я с ней полностью согласен. Но в статье я поднимаю немного другую тему: как сделать так, чтобы даже ошибки возникли система продолжала работать насколько это возможно, а пользователь не сталкивался с крашем, потерей данных или “горящим” интерфейсом и надеждой, что его починят как можно скорее. Идеального кода не бывает, а отказоустойчивость — это как раз про то, что делать, когда идеал дал трещину.

Твой подход зрелый. Но многое зависит от приоритетов в разработке
Подход “assert и немедленный краш” во главу угла ставит целостность системы и прозрачность ошибок
Отказоустойчивый подход во главу угла ставит пользовательский опыт и доступность функционала несмотря на ошибки
(И еще много-много разных подходов)

Универсального и правильного подхода нет

Вы можете корректно и разумно обработать эти события? Обрабатывайте

Это очень точное и правильное уточнение. В статье мне действительно стоило чётко обозначить это

Спасибо за критику — она по делу, уважительная и действительно мне помогает
Очень ценю такие замечания.