Комментарии 40
> Такое поведение для нас вполне приемлемо, если мы случайно не обработали исключение и управляем аварийными стержнями ядерного реактора.
Крайне спорно. Почему приемлемо? Никто даже не узнает, что есть проблема.
Крайне спорно. Почему приемлемо? Никто даже не узнает, что есть проблема.
мне вот спокойнее будет, если 4 из 5 стрежней погрузятся в активную зону реактора, чем если "OUT = NaN" и программа не станет опускать стержни куда надо, а попросит обратиться к разработчику.
Да, потом надо будет зажечь красную лампочку, но… сначала начать выполнять, потом отслеживать выполнение.
Так это же частный случай.
Сценарии работы ответственного оборудования должны быть проработаны всеми видами мыслимых и немыслимых тестов.
В том числе и этот ваш кейс. И лучше, если он все же с грохотом отвалится на тесте, чем в боевом режиме на реакторе.
Сценарии работы ответственного оборудования должны быть проработаны всеми видами мыслимых и немыслимых тестов.
В том числе и этот ваш кейс. И лучше, если он все же с грохотом отвалится на тесте, чем в боевом режиме на реакторе.
Дело скорее в том, что "промышленные" языки не допускают неопределенного поведения программы (привет, С++) и должны детерминированно отрабатывать при любых входных данных.
Если абстрагироваться, это просто разновидность тестирования. И да, действительно, на практике очень разумно. И в то же время, принимая во внимание кол-во возможных состояний любой программы, чуть более сложной, чем helloworld, надежда только на реальное тестирование.
Позволю себе процитировать Дональда Кнута:
Позволю себе процитировать Дональда Кнута:
Опасайтесь багов в приведенном коде; я доказал его корректность, но не запускал.
Дело скорее в том, что «промышленные» языки не допускают неопределенного поведения программы (привет, С++)
Вот уж немного найдется языков программирования более используемых в промышленности, чем C и С++
мне вот спокойнее будет, если 4 из 5 стрежней погрузятся в активную зону реактора, чем если "OUT = NaN" и программа не станет опускать стержни куда надо, а попросит обратиться к разработчику.
… а если наоборот?
Приемлемо не вылететь по исключению, а продолжать управление. Такого рода сбой не повлияет на работу ответственного объекта, а исключение останавливает управление полностью. Как Вы обрабатываете такие исключения, когда от Вас требуется работа 24/7?
Приемлемо не вылететь по исключению, а продолжать управление.
А как мы можем продолжать управление, если наш управляющий код оказался в непредусмотренной ситуации? Откуда гарантия, что он способен продолжать управление корректно?
Как Вы обрабатываете такие исключения, когда от Вас требуется работа 24/7?
Про разделение и супервизию не слышали? Вылетело исключение, актор лег, его рестартовали в заведомо корректном состоянии.
Такое поведение для нас вполне приемлемо, если мы случайно не обработали исключение и управляем аварийными стержнями ядерного реактора.
Искренне надеюсь, что вы не будете программировать не то, что ядерные реакторы, а ничего ответсвеннее поилки для кота.
Почему Вы так не любите кошечек? Они лучше ядерных реакторов, ответственно заявляю. Они мурлыкают!
Так можно получить переполнение кота, тоже нехорошо
Я программист с десятилетним стажем именно промышленного оборудования. Тут приводится пример кода, когда на вход случайно подали не то значение, которое ожидалось (например, ввод оператора). Ползунок со значениями от 0..5 случайно перевели вместо 0 в -1. Что делать программе? Вылететь с ошибкой и остановить объект управления, тот же реактор. Или продолжить управление, игнорируя неправильный ввод. На разных языках программирования, как мы видим, будет различный результат.
Я программист с десятилетним стажем именно промышленного оборудования.
Кошмар.
Тут приводится пример кода, когда на вход случайно подали не то значение, которое ожидалось (например, ввод оператора)… Что делать программе?
Ну, очевидно провалидировать входные значения и сообщить оператору об ошибке, даже не приступая к каким-либо манипуляциям с пресловутыми ядерными стержнями.
А вообще, действительно, расскажите о себе. Очевидно, по образованию вы не программист и в программировании в основном самоучка или изучение программирования было в свое время низкоприоритетным по сравнению с «основной» физикой, математикой или некой инженерией, так? Вы, наверное, уже какой-то старший инженер? Своих новичков тоже учите «проглатывать» ошибки в коде?
Речь идет о случайной ошибке, при которой вся программа останавливается (управление идет в бесконечном цикле), а соответственно и управление объектом. О случайности. Представьте себе, что Вы написали программу управления космическим аппаратом, он вышел на орбиту, обработали все исключения, но это место в коде специально не проверили. Программа написана на языке (выберете любой). Как вы вернете управление обратно? Какое будет поведение при заведомо зашкалившем управляющем воздействии?
Как вы вернете управление обратно? Какое будет поведение при заведомо зашкалившем управляющем воздействии?Против зависаний программы существует watchdog. В экстренной ситуации корабль переводится в «безопасный режим».
Представьте себе, что Вы написали программу управления космическим аппаратом, ..., но это место в коде специально не проверили.Как то не получается такое представить. К написанию программ управления космическими аппаратами обычно подходят очень серьезно. А это значит, что весь код тщательно проверяется на наличие ошибок, а потом еще и тестируется в условиях, максимально приближенных к реальным. А о «случайной ошибке» и речи идти не может, потому что любая ошибка — это труба космическому аппарату стоимостью в сколько то там миллионов долларов. Так что без разницы, как на нее реагируют приведенные Вами языки в Вашей конфигурации.
обработали все исключения, но это место в коде специально не проверили.
То есть напрямую нарушили стандарт разработки. Печально. Усталые люди в форме или в штатском будут долго и муторно выяснять был ли умысел ( работает ли программист на румынскую разведку или начитался таких вот статей на хабре ) и по итогам определят, кто направляется в Магадан, а кто просто будет всю оставшуюся жизнь работать таксистом.
А на космическом аппарате, как и при любой аварии, вступает в дело независимая аварийная система. Что тут неожиданного?
habr.com/company/mailru/blog/370153
всякое бывает
всякое бывает
О так там практически все ошибки в вашем духе, тупо забивали на валидацию и продолжали работу как есть. В вашем случае только повезло что сама логика программы прощает подобную ошибку.
Возможно, мою статью, не так поняли, как я того хотел. Дописал UPD.
Ды как её ещё можно понять? Если во время переписывания кода, на другой язык вы находите ошибку, её нужно исправлять, а не писать обёртку, или надеяться на язык, причём исправлять и в новом коде и в старом. А если вы переписали и не заметили ошибку, то как вы сможете обработать её если вы её не заметили? Статья капитанская, и так очевидно, что при переносе нужно учитывать особенности языка, а учитывать особенности выполнения заведомого неправильного кода, это как-то тупо мягко говоря.
Например, взятие элементов массива по несуществующему индексу на разных языках дает разные результаты. Если не провалидировать индексную переменную в цикле, то, одинаковая программа поведет себя совершенно по разному, от «падения», до выдачи непредсказуемых результатов. Некоторые языки это могут «простить», некоторые завершить выполнение с FATAL ERROR.
Речь идет о случайной ошибке, при которой вся программа останавливается (управление идет в бесконечном цикле), а соответственно и управление объектом.
А как вы от "в определенных условиях бросается исключение" переходите к "вся программа [хотя правильно тут говорить об аппаратно-программном комплексе] останавливается"?
Тут приводится пример кода, когда на вход случайно подали не то значение, которое ожидалось (например, ввод оператора).
У вас в промышленном оборудовании нет проверки на вводимые значения?
Ползунок со значениями от 0..5 случайно перевели вместо 0 в -1.
Он на то и ползунок, чтобы его нельзя было выставить в -1.
Мда… Я-то думал, что тут какие-то тонкости при переводе корректной программы, а тут сравнение результатов для заведомо некорректной.
Соглашусь с j_wayne — в вашем случает лучше бы программа сразу упала, тогда вы бы заметили проблему.
Вы, я так понимаю, про fail early не слышали?
> Такое поведение для нас вполне приемлемо, если мы случайно не обработали исключение и управляем аварийными стержнями ядерного реактора.
Хорошо, что те кто пишут всякий safe-critical, не считают подобное поведение приемлимым.
Хорошо, что те кто пишут всякий safe-critical, не считают подобное поведение приемлимым.
Выводы, конечно, просто божественны.
Поэтому не все языки подходят для решения ответственных задач или требуют дополнительных проверок и ветвлений кода.Я бы здесь слово «языки» заменил на «люди».
То есть такой же, как и до ошибки. Программа не бросила исключение, а просто проигнорировала несуществующий элемент. Такое поведение для нас вполне приемлемо, если мы случайно не обработали исключение и управляем аварийными стержнями ядерного реактора.А если что нть посложнее, чем просто сумму всех элементов взять, например среднее значение всех элементов?
Мне довольно часто приходится переводить программы с одних языков на другие. Как исходная программа должна работать — задача заказчика, и он же должен предоставить какие-то тесты (ведь он же ее будет принимать!). Сначала перевожу как вижу, потом беру входные данные от заказчика, проверяю на исходной программе и сравниваю с результатом моего перевода. Если что-то не так — в каждую функцию или метод в начале вставляю вывод в STDERR всех параметров, которые были переданы (и в исходный вариант, и в свой). Да, там может быть куча вывода, но сравнилкой файлов достаточно найти самое первое различие — и всё, дальше думать что не так. Ну и так далее. И да, ядерные реакторы я не программирую :)
Для Javascript правильнее было бы указать, что доступ к несуществующему элементу массиву вернет undefined. Потому что только в примере выше автор получил в качестве результата NaN, пытаясь сложить число и undefined. Если бы это было склеивание строк, например «my string» + undefined, то результат был бы иным: «my stringundefined». И если полученное в качестве результата значение NaN впоследствии могло бы вызвать сбой дальше по коду, хоть как-то указав, где закралась ошибка, то строка «my stringundefined» ошибки не вызовет и программа продолжит работать неправильно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Доступ к несуществующему индексу массива