Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 36
На сколько вольт? На 250 хватит?
Не хватит, амплитудное значение напряжения в розетке - 325 В (при 230 В номинальных)
Проверьте осциллографом. Вы удивитесь. Полная амплитуда намного больше.
поэтому кондеры на 250В можно пользоваться в католических сетях 110AC, а в православных- надо брать конедеры на 400V. и перед ними ставить еще цепь безопасности, разрядник там, с плавкой вставкой, или еще какой элемент, чтоб снизить вероятность смерти оборудования от случайно клинанувшего в соседней стене промышленного перфоратора. А я как-то выносил технику из офиса, у которого на этаже клинанул такой перфоратор- половина входных цепей погорела, компы, МФУшки, принтеры. Было забавно- весь этаж небольшого офисного здания- комнат двенадцать- выносили сгоревшее офисное железо, включая даже один холодильник.
И, по-хорошему, ещё неплохо ставить реле напряжения (а там, где известно, что оно и так нестабильное, и вовсе обязательно). Стоимость типичного экземпляра обычно вдесятеро окупается после первого же его срабатывания.
Так ведь отличный исход для производителей данного оборудования. На защиту цепей тратиться не пришлось, выход из строя по чужой вине, клиент придет купить еще раз
как его могли написать программисты, которые «знали о возможном наступлении проблемы, но самонадеянно полагали ее избежать»?
Ха, привет ошибка 2000 года. Но мир как-то выжил.
А что, если память не выделилась? И ведь это можно проверить прямо там, в коде — «а зачем?»
Ну, если проверять это каждый раз, то никаких проверок не хватит. А общая обработка таких исключений на верхнем уровне грамотно убьёт процесс с правильным информирование об ошибке.
Создадим новый язык программирования,в котором в NULL писать безопасно.
Так уже создали - bash. Писать в /dev/null вполне себе безопасно. И главное, очень быстро. Прямо очень очень быстро)
Что вы имеете в виду под верхним уровнем? Если ОС, то у неё немного выбора: убить процесс или оставить. Тут ещё вопрос, кого убивать надо: кто последний, тот и папа или самого прожорливого. А если верхний уровень программы, так это база, как мне казалось, - централизованное управление памятью.
Вообще, именно этот случай у меня вызывает протест. Работаешь на низком уровне - будь готов всё ссылки проверять. Или бери другой ЯП. А 64ГБ - просто оправдание своей лени.
Верхний уровень программы, конечно. Только это никакое не централизованное управление памятью, а централизованное управление исключениями. На верхнем уровне программы могут обрабатывать я все не обработанные ниже исключения, как то: нехватка памяти, доступ к не своему адресу (сюда же к null), исключение сына из детсада.
И именно с такой центральной обработкой исключений не надо проверять все ссылки - это просто не имеет никакого смысла.
Так ошибка 2000 года это как раз таки обратный кейс. На её исправление направили огромное количество сил, когда встал вопрос медленно приближающегося Миллениума, и тем самым нивелировали основной пласт проблем.
Как вообще может существовать софт, точнее, как его могли написать программисты, которые «знали о возможном наступлении проблемы, но самонадеянно полагали ее избежать»
так весь мир разработки пляшет под time-to-market же. А хорошая валидация, обработка ошибок и безопасность - противоположна этому принципу. Вот и получается у нас 15 действий по цепочке с одним обработчиком ошибок "что-то пошло не так!", либо вообще без обработчиков. Собственно и покрытие тестами то - покрывает фичи, а вовсе не выход за граничные условия и отсутствие ресурсов. Так что мы такие случаи с текущим подходом не найдем никогда, кроме как случайно лбом.
А хорошая валидация, обработка ошибок и безопасность
Почему мы этим не занимаемся - понятно. Но почему этим не занимаются те, у кого бюджеты безлимитные (всякие faangи, банки и другие корпорации с капитализацией в миллиард) - большой вопрос.
Потому что "Можно. А зачем?" (c)
Но если серьёзно, в реальности то чем отличаются ребята с условно-бесконечными бюджетами? Там тоже time-to-market в топе требований. Ну и объективно, ни у кого в топе рынка не выходит "вусмерть забагованное до состояние неюзабельности". Ключевые задачи пользователей они как правило решают достаточно стабильно, чтоб пользоваться их софтом и тратить на него деньги.
Ну и объективно, ни у кого в топе рынка не выходит "вусмерть забагованное до состояние неюзабельности". Ключевые задачи пользователей они как правило решают достаточно стабильно, чтоб пользоваться их софтом и тратить на него деньги.
А как же вопрос репутации? Всякие "Приложение криво выглядит на смартфонах с небольшим размером экрана - это недопустимо для организации нашего уровня" или "Заказчик сообщил о примитивном баге - это позор для компании с нашим именем!"
Тут обратная связь.
Именно потому у них бюджеты и безлимитные, что они не тратят деньги на разную ненужную (им) ерунду - "этим не занимаются" (с).
Наличие бюджета само по себе никак не влияет на обработку ошибок.
Потому что сначала всегда и везде пишут и отлаживают happy path, т.е. работу программы в штатном режиме. Т.е. чтобы она тупо выполняла свою задачу хотя бы в тепличных условиях. Без этого она как бы и не нужна совсем.
Обработка ошибок (именно обработка, а не просто выбрасывание исключений на любой чих) делается уже поверх отлаженного happy path. Вот только все дедлайны к этому моменту, как правило, уже просраны, а релиз должен был быть позавчера. Купить время за деньги, увы, не получается.
Вот и получается у нас 15 действий по цепочке с одним обработчиком ошибок "что-то пошло не так!", либо вообще без обработчиков.
Забавно, но когда-то именно это считалось причиной победы Linux. В других уже умерших коммерческих ОС облепляли всё на свете проверками на ошибки, тратили много времени и денег. А в Linux был kernel panic. Сейчас про это уже забыли.
В Линуксе в цепочке cat xx | grep ddd |awk | sed | tail | blaablaba каждая отдельная программа способна:
1 - писать не только в stdout, но и в stderr
2 - завершать своё исполнение с кодом ошибки
Вместе это создает прекрасную возможность отслеживания ошибок на каждой конкретной стадии, а если нельзя предусмотреть их заранее (например, возможно отсутствие строки для grep) - то условные операторы и код завершения помогут проблему купировать.
Какой еще kernel panic и причем он тут?!
А почему нельзя, наконец, сделать лимит на пожирание памяти джаваскриптом в браузере? Ах да, кажется, тогда gmail.com первым перестанет работать.
о5 JS виноват, ух какой
как его могли написать программисты, которые «знали о возможном наступлении проблемы, но самонадеянно полагали ее избежать»?
Ответ: только он и может существовать. Потому что программист должен сделать быстро и дешево. Или его уволят. Программист, который придёт к хозяину со словами "я хочу потратить на программу в 5 раз больше времени и вытащить из вашего кошелька в 5 раз больше зарплаты сегодня, потому что может быть где-то в Сомали через пару лет кто-то обкурится и начнёт отстреливать каждый шестой пакет" рисует себе на спине большую такую мишень. Сегодня рисует, а не через 5 лет.
Если вам интереснее подробнее и с примерами - просто прочитайте "The rise of worser is better"
А что за ?? я вижу в последнее время везде на хабре?
Что-то я не пойму.
Даже ИИ при упоминания malloc СРАЗУ ЖЕ выдаетarr = (int*)malloc(n*sizeof(int)); // Приведение типа к (int*)
if (arr == NULL) { // Обязательная проверка на NULL
printf("Не удалось выделить память\n");...А вообще-то статья является переформулировкой закона Мёрфи.
«Если есть вероятность того, что какая-нибудь неприятность может случиться, то она обязательно произойдет».
https://old.mista.ru/merfy/index.html
Оно обязательно сломается, нужно просто рассчитывать на это заранее и немного подстраховаться.
От всего подстраховаться невозможно - в одних случаях элементарно не хватит денег, в других - невозможно в принципе, например, от конца света (землетрясение, астероид, третья мировая и т.д.). Вопрос в правильной оценке вероятности поломки и расчете объема ресурсов, которые можно выделить на ее предотвращение. Например, при разработке радиолокационных систем устанавливают разные вероятности пропуска цели и ложного обнаружения. И никто не требует достижения нулевых значений.
Есть понятие условий эксплуатации. Если блок питания рассчитан на работу в однофазной сети - это значит, что кто-то другой обязан обеспечить ему параметры этой однофазной сети. Но, конечно же, общее разгильдяйство никто не отменял.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оно обязательно сломается: не «если», а «когда»