Привет, пользователи Habr. Спасибо за критику. Я её учел и отредактировал публикацию: добавил больше примеров и уточнений и постарался сделать спорные моменты более однозначными и прозрачными
Понимаю твою позицию, но, кажется, ты говоришь про неудачную попытку «спрятать» ошибку - я же пишу о том, как грамотно её обработать, чтобы не навредить ещё больше.
Пример с текстовым редактором - отличный. Но он как раз в пользу отказоустойчивости: при нехватке памяти правильнее не крашиться, а остановить операцию, сохранить то, что уже есть, и честно сообщить об ошибке пользователю (например, показав всплывающее уведомление). Это не «маскировка», а забота о пользователе.
Отказоустойчивость - не про «продолжать несмотря ни на что» (даже ценой утечек), а про то, чтобы не усугубить ситуацию, когда что-то пошло не так
Надеюсь мне удалось лучше передать смысл этой публикации
Я так выражаюсь лишь из-за того, что переживаю. Это моя первая публикация за всю карьеру, и я боюсь оступиться, чтобы не получить “расстрела” от таких, как ты. Такой стиль дает мне чувствовать себя как за "броней". Даже если эта броня мнимая. В будущем мне будет легче выражаться проще
Еще хочу сказать спасибо за то, что пытаешься помочь мне, показывая, что выбранный мною подход, мягко говоря, оказался далеко не лучшим
Расстраивает, что такой стиль общения присваивают ИИ. Забывая, что тот не изобрел его, а лишь подражает. Люди умели так писать и выражаться задолго до него. Словно мне следует, так же как и ты, в конце ставить “:)”, чтобы это делало меня “живее”. Я лишь стараюсь не впадать в негатив, сохранять уважительный тон и честно признавать ошибки. Это куда лучше, чем отвечать той же монетой
К тому же ИИ уже давно умеет общаться в разных стилях — в том числе с иронией, добавляя ":)" в конце.
А, вот откуда появлется куча "программистов", постоянно использующих паттерн:
let data; try
{
data = this.getSomeData(); } catch(error)
{ data = this.getErrorData();
console.error(error); }
this.doSomething(data);
Я с тобой согласен. Ме стоило добавить уточнение, когда такой паттерн действительно уместен. Например, при рискованных операциях на стороне браузера, которые могут выбросить ошибку — это браузерные API, которые пользователь может отключить, или ситуации с нехваткой времени или ресурсов, из-за чего вызов может завершиться с ошибкой (например, доступ к LocalStorage, запрос разрешения на камеру или микрофон). В таких случаях обработка через try/catch с запасным вариантом данных оправдана. Я не вкладывал смысл в то, что его нужно использовать везде и всегда. Но там, где ошибка может возникнуть, но не может быть исправлена - он уместен (тот же пример с нехваткой памяти на стороне пользователя).
Самый разумный подход: это при обнаружении ошибки, которую вы не знаете как можно обработать - немедленно паниковать с сохранением достаточной информации (где и почему) запаниковало.
Подход с немедленной паникой при любой непредвиденной ошибке, безусловно, разумен. Но это совсем не про отказоустойчивость. Мне кажется, что ты больше о стремлении писать код, о том как не допускать ошибки (допускать меньше). Это правильная цель — и я с ней полностью согласен. Но в статье я поднимаю немного другую тему: как сделать так, чтобы даже ошибки возникли система продолжала работать насколько это возможно, а пользователь не сталкивался с крашем, потерей данных или “горящим” интерфейсом и надеждой, что его починят как можно скорее. Идеального кода не бывает, а отказоустойчивость — это как раз про то, что делать, когда идеал дал трещину.
Твой подход зрелый. Но многое зависит от приоритетов в разработке Подход “assert и немедленный краш” во главу угла ставит целостность системы и прозрачность ошибок Отказоустойчивый подходво главу угла ставит пользовательский опыт и доступность функционала несмотря на ошибки (И еще много-много разных подходов)
Универсального и правильного подхода нет
Вы можете корректно и разумно обработать эти события? Обрабатывайте
Это очень точное и правильное уточнение. В статье мне действительно стоило чётко обозначить это
Спасибо за критику — она по делу, уважительная и действительно мне помогает Очень ценю такие замечания.
Ты прав, примеров и впрям мало, стоило добавить больше. В названии я хотел сделать акцент на том, что примеры будут именно на JavaScript, а не на их количество. Учту это на будущее и постараюсь делать материал более насыщенным
Нет ссылки на источники — где исследование, кто его проводил, где данные? Нет логов партий, переписки, описания условий — только пересказ со слов. Всё выглядит как фанфик: «хладнокровно предала», «удар в спину», «яростная агрессия» — будто не модели играли, а герои подросткового романа. Как вообще модели подключались к игре? Через API? Какой был интерфейс? Где информация, на основе которой они принимали решения? У всех ли был одинаковый доступ? Были ли запуски с разными seed? Всё это вызывает вопросы, а ответов нет. В итоге материал выглядит скорее как выдумка или вирусный вброс, чем как реальное исследование.
Привет, пользователи Habr. Спасибо за критику. Я её учел и отредактировал публикацию: добавил больше примеров и уточнений и постарался сделать спорные моменты более однозначными и прозрачными
Понимаю твою позицию, но, кажется, ты говоришь про неудачную попытку «спрятать» ошибку - я же пишу о том, как грамотно её обработать, чтобы не навредить ещё больше.
Пример с текстовым редактором - отличный. Но он как раз в пользу отказоустойчивости: при нехватке памяти правильнее не крашиться, а остановить операцию, сохранить то, что уже есть, и честно сообщить об ошибке пользователю (например, показав всплывающее уведомление). Это не «маскировка», а забота о пользователе.
Отказоустойчивость - не про «продолжать несмотря ни на что» (даже ценой утечек), а про то, чтобы не усугубить ситуацию, когда что-то пошло не так
Надеюсь мне удалось лучше передать смысл этой публикации
Я так выражаюсь лишь из-за того, что переживаю. Это моя первая публикация за всю карьеру, и я боюсь оступиться, чтобы не получить “расстрела” от таких, как ты. Такой стиль дает мне чувствовать себя как за "броней". Даже если эта броня мнимая. В будущем мне будет легче выражаться проще
Еще хочу сказать спасибо за то, что пытаешься помочь мне, показывая, что выбранный мною подход, мягко говоря, оказался далеко не лучшим
Расстраивает, что такой стиль общения присваивают ИИ. Забывая, что тот не изобрел его, а лишь подражает. Люди умели так писать и выражаться задолго до него. Словно мне следует, так же как и ты, в конце ставить “:)”, чтобы это делало меня “живее”. Я лишь стараюсь не впадать в негатив, сохранять уважительный тон и честно признавать ошибки. Это куда лучше, чем отвечать той же монетой
К тому же ИИ уже давно умеет общаться в разных стилях — в том числе с иронией, добавляя ":)" в конце.
Я с тобой согласен. Ме стоило добавить уточнение, когда такой паттерн действительно уместен. Например, при рискованных операциях на стороне браузера, которые могут выбросить ошибку — это браузерные API, которые пользователь может отключить, или ситуации с нехваткой времени или ресурсов, из-за чего вызов может завершиться с ошибкой (например, доступ к LocalStorage, запрос разрешения на камеру или микрофон). В таких случаях обработка через try/catch с запасным вариантом данных оправдана.
Я не вкладывал смысл в то, что его нужно использовать везде и всегда. Но там, где ошибка может возникнуть, но не может быть исправлена - он уместен (тот же пример с нехваткой памяти на стороне пользователя).
Подход с немедленной паникой при любой непредвиденной ошибке, безусловно, разумен. Но это совсем не про отказоустойчивость.
Мне кажется, что ты больше о стремлении писать код, о том как не допускать ошибки (допускать меньше). Это правильная цель — и я с ней полностью согласен. Но в статье я поднимаю немного другую тему: как сделать так, чтобы даже ошибки возникли система продолжала работать насколько это возможно, а пользователь не сталкивался с крашем, потерей данных или “горящим” интерфейсом и надеждой, что его починят как можно скорее. Идеального кода не бывает, а отказоустойчивость — это как раз про то, что делать, когда идеал дал трещину.
Твой подход зрелый. Но многое зависит от приоритетов в разработке
Подход “assert и немедленный краш” во главу угла ставит целостность системы и прозрачность ошибок
Отказоустойчивый подход во главу угла ставит пользовательский опыт и доступность функционала несмотря на ошибки
(И еще много-много разных подходов)
Универсального и правильного подхода нет
Это очень точное и правильное уточнение. В статье мне действительно стоило чётко обозначить это
Спасибо за критику — она по делу, уважительная и действительно мне помогает
Очень ценю такие замечания.
Ты прав, примеров и впрям мало, стоило добавить больше. В названии я хотел сделать акцент на том, что примеры будут именно на JavaScript, а не на их количество. Учту это на будущее и постараюсь делать материал более насыщенным
Нет ссылки на источники — где исследование, кто его проводил, где данные? Нет логов партий, переписки, описания условий — только пересказ со слов. Всё выглядит как фанфик: «хладнокровно предала», «удар в спину», «яростная агрессия» — будто не модели играли, а герои подросткового романа. Как вообще модели подключались к игре? Через API? Какой был интерфейс? Где информация, на основе которой они принимали решения? У всех ли был одинаковый доступ? Были ли запуски с разными seed? Всё это вызывает вопросы, а ответов нет. В итоге материал выглядит скорее как выдумка или вирусный вброс, чем как реальное исследование.