Design by contract (TM) (also called Contract Programming) is another example of a Fail fast! feature. This is because invalid values for input/output arguments and object attributes are immediately detected and raise a program error at runtime.
There are many more Fail fast! features that can be built into a programming language.
После того как написал текст про исключения мне были представлены два факта:
1) Текст получился сумбурным
2) Я описал Fail fast! подход.
Хорошенько разобравшись в ситуации понял, что лучше мне не пытаться рассказывать об этом самостоятельно, а перевести уже существующую статью. Тем более что на русском материалов на эту тему парктически нет.
Пример про Гагарина — один в один пример про ракету на Марсе из статьи. Где как раз и говорится, что в этой ситуации надо использовать Forgive.
Действительно создается ощущение что статьюв ы не дочитали.
Хм. Два часа ночи дают о себе знать.
«не было никакого смысла отправлять в релиз ПО с fail fast»
«нет никакого смысла в том»
«автоматизируют обработку ошибок и отправку отчетов на Windows»
Тут есть нюанс.
Под виндой, особенно раньше, не было никакого смысла в релиз ПО с fail fast. Потому что без поддержки отчетов об ошибках отсылаемых разработчикам нет никакого смысла от того, что программа на стороне пользователя упала.
Но сейчас ситуация иная.
Есть множество инструментов, которые автоматизируют обработку ошибок на Windows и можно быть уверенным, что падение не будет бесполезным.
На Андроиде так вообще уже встроенная система отчетов используется.
Ну и исправление ошибки пользователем очень уж специфичная вещь не так уж часто встречается, чтобы при разработке на этот момент обращать внимание.
Ответ достаточно очевиден:
Выгрузить драйвер, написать в журанл об этом, сообщить пользователю что в драйвере произошла ошибка.
Если есть информацию о разработчиках драйвера — отослать им отчет об ошибке.
fail fast тут не применим, потому что задача fail fast обрабатывать ситуации нерпедсказуемые, а не полностью заменять обработку ошибок.
Цель вашего вопроса показать, что fail fast не применим в 100% случаев?
Ну так об это и в тексте написано. Никто не предлагает пихать fail fast без разбору везде.
Тебе поможет железяка под названием ELM327. Стоит не особо дорого.
Умеет работать с бортовыми компьютерыми и передавать данные на RS232 или Bluetooth.
Ее протокол в свободном доступе. Сможет передать все что ей расскажет бортовой компьютер.
Удачи!
Решение более чем спорное, но интересное и результат дает — на выходе отчет об ошибке с call stack внутри.
Хотя мне видится, что включить исключения является значительно более корректным решением.
Ну это клево, когда фирма может для разработки мелких андроид игр нанимать профессионалов с зарплатой в 2-3 000$. Но не все так могут. Гораздо проще научиьт человека выдавать код легко проверяемый тестами, чем нанимать супер профи.
Смею предположить что не только мы используем эникейщиков для простых задач… Судя по тому, как много косяк в существующем софте. Видимо программисты пищущие фотошоп, open office и другой софт не настолько круты и не могут гарантировать что их ошибки не дойдут до продакшена. :)
Елинственное, не понятно, почему вы шлете репорт только на мобильной версии.
На десктопе это даже актуальнее, потому что на декстопе отсутствуют встроенные инстурменты оповещения об ошибке.
«В продакшн не попадет» — откуда такое утверждение?
У нас как раз код с похожей ошибкой мог уйти в продакшн, если бы его замаскировали проверкой и выводом в лог.
Метод активирующий вибрацию содержал ошибку в названии. На устройствах программистов просто нет вибрации и ошибку никто не засек.
Засекли, когда на устройстве тестера игра свалилась в исключение.
Была бы там маскировка и вывод в лог — вполне могли пропустить в продакшн, тесте вполне мог не обратить внимание что вибрация не срабатывает когда должна, а уж лог анализировать в его задачи не входит.
А так исключение, баг репорт, фикс. Все счастливы.
Каким образом вы гарантируете, что баг с такой маскировкой не пройдет мимо тестера?
И вообще, зачем молчать о баге на этапе тестирования?
По поводу конкретного примера — как я уже сказал и в этом примере маскировка совершенно лишняя.
Ну и в целом пример значения не имеет. Примеров таких миллиард и простые эникейщики перетаскивают эти првоерки даже не задумываясь как они будут работать в реальном продукте.
Надо ловить исключения.
Надо продолжать работу, если исключение не критичное.
Речь исключительно о пустых проверках. Лучше не делать вообще ничего, чем максировать ошибку бесполезной проверкой.
Пост и не стал бы писать, но количество примеров с пустыми максировками просто зашкаливает. Каждый автор примеров считает своим долгом напихать в код проверок, которые там не нужны.
Проверка из приведенного примера плоха в своей сути.
Нет никакого смысла писать ошибку в лог. Надо либо возбуждать исключение, либо посылать отчет либо еще как-то реагировать. Но уж точно не ограничиваться выходом с записью в лог, которую никто не увидит.
О чем?
Про ЗБТ ничего не говорил.
Что же это, как не продажа за полцены забагованного приложения?
В идеальном мире.
Вспомните сколько раз падали сервера Diablo 3 за время с его старта.
В программировании подругому и не бывает.
1) Текст получился сумбурным
2) Я описал Fail fast! подход.
Хорошенько разобравшись в ситуации понял, что лучше мне не пытаться рассказывать об этом самостоятельно, а перевести уже существующую статью. Тем более что на русском материалов на эту тему парктически нет.
Действительно создается ощущение что статьюв ы не дочитали.
«не было никакого смысла отправлять в релиз ПО с fail fast»
«нет никакого смысла в том»
«автоматизируют обработку ошибок и отправку отчетов на Windows»
Под виндой, особенно раньше, не было никакого смысла в релиз ПО с fail fast. Потому что без поддержки отчетов об ошибках отсылаемых разработчикам нет никакого смысла от того, что программа на стороне пользователя упала.
Но сейчас ситуация иная.
Есть множество инструментов, которые автоматизируют обработку ошибок на Windows и можно быть уверенным, что падение не будет бесполезным.
На Андроиде так вообще уже встроенная система отчетов используется.
Ну и исправление ошибки пользователем очень уж специфичная вещь не так уж часто встречается, чтобы при разработке на этот момент обращать внимание.
Выгрузить драйвер, написать в журанл об этом, сообщить пользователю что в драйвере произошла ошибка.
Если есть информацию о разработчиках драйвера — отослать им отчет об ошибке.
fail fast тут не применим, потому что задача fail fast обрабатывать ситуации нерпедсказуемые, а не полностью заменять обработку ошибок.
Ну так об это и в тексте написано. Никто не предлагает пихать fail fast без разбору везде.
Умеет работать с бортовыми компьютерыми и передавать данные на RS232 или Bluetooth.
Ее протокол в свободном доступе. Сможет передать все что ей расскажет бортовой компьютер.
Удачи!
Решение более чем спорное, но интересное и результат дает — на выходе отчет об ошибке с call stack внутри.
Хотя мне видится, что включить исключения является значительно более корректным решением.
Смею предположить что не только мы используем эникейщиков для простых задач… Судя по тому, как много косяк в существующем софте. Видимо программисты пищущие фотошоп, open office и другой софт не настолько круты и не могут гарантировать что их ошибки не дойдут до продакшена. :)
Елинственное, не понятно, почему вы шлете репорт только на мобильной версии.
На десктопе это даже актуальнее, потому что на декстопе отсутствуют встроенные инстурменты оповещения об ошибке.
У нас как раз код с похожей ошибкой мог уйти в продакшн, если бы его замаскировали проверкой и выводом в лог.
Метод активирующий вибрацию содержал ошибку в названии. На устройствах программистов просто нет вибрации и ошибку никто не засек.
Засекли, когда на устройстве тестера игра свалилась в исключение.
Была бы там маскировка и вывод в лог — вполне могли пропустить в продакшн, тесте вполне мог не обратить внимание что вибрация не срабатывает когда должна, а уж лог анализировать в его задачи не входит.
А так исключение, баг репорт, фикс. Все счастливы.
Каким образом вы гарантируете, что баг с такой маскировкой не пройдет мимо тестера?
И вообще, зачем молчать о баге на этапе тестирования?
По поводу конкретного примера — как я уже сказал и в этом примере маскировка совершенно лишняя.
Ну и в целом пример значения не имеет. Примеров таких миллиард и простые эникейщики перетаскивают эти првоерки даже не задумываясь как они будут работать в реальном продукте.
Надо продолжать работу, если исключение не критичное.
Речь исключительно о пустых проверках. Лучше не делать вообще ничего, чем максировать ошибку бесполезной проверкой.
Пост и не стал бы писать, но количество примеров с пустыми максировками просто зашкаливает. Каждый автор примеров считает своим долгом напихать в код проверок, которые там не нужны.
Проверка из приведенного примера плоха в своей сути.
Нет никакого смысла писать ошибку в лог. Надо либо возбуждать исключение, либо посылать отчет либо еще как-то реагировать. Но уж точно не ограничиваться выходом с записью в лог, которую никто не увидит.