Навеяло несколькими прочитанными недавно статьями и комментариями к ним.
Люди, помните - "дерьмо случается"! Конечно, хорошо жить в мире где всё идет строго по плану, работает без ошибок и сбоев, никто не пытается ни в чем навредить и так далее - от только где он, этот мир?
Вот недавнее: джава-скрипты в браузере сожрали кучу памяти, потому что где-то на роутере пакеты не проходили так, как от них ожидалось.
Хорошо, конечно, что причину удалось найти — но как вообще могло такое получиться?
Что, если между браузером и сайтом будет 100 500 узлов, 13 стран, и пара ТСПУ, на которых кто‑то решит бороться с мошенниками, делая обрезание каждому 6 пакету?
Гарантий — никаких. Как вообще может существовать софт, точнее, как его могли написать программисты, которые «знали о возможном наступлении проблемы, но самонадеянно полагали ее избежать»?
Или вот пишет кто‑то программу, запрашивает память — немного, всего пару сотен мегабайт — подумаешь, ведь у него на машине 64 гигабайта!
А что, если память не выделилась? И ведь это можно проверить прямо там, в коде — «а зачем?» ©
Но вот у кого‑то браузер как раз сожрал всю память, залез в своп и сожрал его тоже, и теперь несчастная программа, попросив всего‑то жалкие 200 мегабайт памяти под буфер — получает NULL.
И тут же отважно лезет что‑то писать по этому адресу. Кто виноват? Конечно, зловредный NULL, давайте с ним бороться! Создадим новый язык программирования,в котором в NULL писать безопасно.
У кого-то та же история с файлом: файл открыт, данные в него пишутся, пишутся в него данные... А проверять будет Пушкин, Александр Сергеевич - что места на диске давно нет.
И такое повсеместно. Взять, к примеру, аккумуляторы - по идее их может защитить BMS, но "BMS это зло - она может отключить батарею, и что-то где-то сгорит/заклинит/перевернется!"
Но ведь батарея может отключиться по любой дргой причине — проводок оторвался, гаечка открутилась, шаловливые ручки забыли затянуть — так что теперь, всё должно сразу сгорать?
Или вот блоки питания: кто не слышал про «220В в розетке»?
А если их выпрямить и поставить сглаживающий конденсатор? На сколько вольт? На 250 хватит?
Но забывают что сеть всегда 3-фазная, и если где‑то в квартире всего одна фаза — значит где‑то в другой — вторая. Её, вторую, кто‑то закоротит на «нейтраль» — а на вашей появится 380В межфазного напряжения.
И вот пошла гореть аппаратура по квартирам... Солидные, большие компании делали, не DIY какой‑нибудь...
Ну как так-то? Оно обязательно сломается, нужно просто рассчитывать на это заранее и немного подстраховаться.
Комментарии (34)
dyadyaSerezha
24.01.2026 00:29как его могли написать программисты, которые «знали о возможном наступлении проблемы, но самонадеянно полагали ее избежать»?
Ха, привет ошибка 2000 года. Но мир как-то выжил.
А что, если память не выделилась? И ведь это можно проверить прямо там, в коде — «а зачем?»
Ну, если проверять это каждый раз, то никаких проверок не хватит. А общая обработка таких исключений на верхнем уровне грамотно убьёт процесс с правильным информирование об ошибке.
Создадим новый язык программирования,в котором в NULL писать безопасно.
Так уже создали - bash. Писать в /dev/null вполне себе безопасно. И главное, очень быстро. Прямо очень очень быстро)
bbc_69
24.01.2026 00:29Что вы имеете в виду под верхним уровнем? Если ОС, то у неё немного выбора: убить процесс или оставить. Тут ещё вопрос, кого убивать надо: кто последний, тот и папа или самого прожорливого. А если верхний уровень программы, так это база, как мне казалось, - централизованное управление памятью.
Вообще, именно этот случай у меня вызывает протест. Работаешь на низком уровне - будь готов всё ссылки проверять. Или бери другой ЯП. А 64ГБ - просто оправдание своей лени.
dyadyaSerezha
24.01.2026 00:29Верхний уровень программы, конечно. Только это никакое не централизованное управление памятью, а централизованное управление исключениями. На верхнем уровне программы могут обрабатывать я все не обработанные ниже исключения, как то: нехватка памяти, доступ к не своему адресу (сюда же к null), исключение сына из детсада.
И именно с такой центральной обработкой исключений не надо проверять все ссылки - это просто не имеет никакого смысла.
Forthright
24.01.2026 00:29Так ошибка 2000 года это как раз таки обратный кейс. На её исправление направили огромное количество сил, когда встал вопрос медленно приближающегося Миллениума, и тем самым нивелировали основной пласт проблем.
dyadyaSerezha
24.01.2026 00:29Что там потом было с этой ошибкой, это уже другая история. Я же про сам оригинал, так сказать. Не писали бы программы из расчёта на 5 лет, не было и вовсе никакой проблемы 2000 года.
mixsture
24.01.2026 00:29Как вообще может существовать софт, точнее, как его могли написать программисты, которые «знали о возможном наступлении проблемы, но самонадеянно полагали ее избежать»
так весь мир разработки пляшет под time-to-market же. А хорошая валидация, обработка ошибок и безопасность - противоположна этому принципу. Вот и получается у нас 15 действий по цепочке с одним обработчиком ошибок "что-то пошло не так!", либо вообще без обработчиков. Собственно и покрытие тестами то - покрывает фичи, а вовсе не выход за граничные условия и отсутствие ресурсов. Так что мы такие случаи с текущим подходом не найдем никогда, кроме как случайно лбом.
Femistoklov
24.01.2026 00:29А хорошая валидация, обработка ошибок и безопасность
Почему мы этим не занимаемся - понятно. Но почему этим не занимаются те, у кого бюджеты безлимитные (всякие faangи, банки и другие корпорации с капитализацией в миллиард) - большой вопрос.
Newbilius
24.01.2026 00:29Потому что "Можно. А зачем?" (c)
Но если серьёзно, в реальности то чем отличаются ребята с условно-бесконечными бюджетами? Там тоже time-to-market в топе требований. Ну и объективно, ни у кого в топе рынка не выходит "вусмерть забагованное до состояние неюзабельности". Ключевые задачи пользователей они как правило решают достаточно стабильно, чтоб пользоваться их софтом и тратить на него деньги.
Femistoklov
24.01.2026 00:29Ну и объективно, ни у кого в топе рынка не выходит "вусмерть забагованное до состояние неюзабельности". Ключевые задачи пользователей они как правило решают достаточно стабильно, чтоб пользоваться их софтом и тратить на него деньги.
А как же вопрос репутации? Всякие "Приложение криво выглядит на смартфонах с небольшим размером экрана - это недопустимо для организации нашего уровня" или "Заказчик сообщил о примитивном баге - это позор для компании с нашим именем!"
Arioch
24.01.2026 00:29Тут обратная связь.
Именно потому у них бюджеты и безлимитные, что они не тратят деньги на разную ненужную (им) ерунду - "этим не занимаются" (с).
vanxant
24.01.2026 00:29Наличие бюджета само по себе никак не влияет на обработку ошибок.
Потому что сначала всегда и везде пишут и отлаживают happy path, т.е. работу программы в штатном режиме. Т.е. чтобы она тупо выполняла свою задачу хотя бы в тепличных условиях. Без этого она как бы и не нужна совсем.
Обработка ошибок (именно обработка, а не просто выбрасывание исключений на любой чих) делается уже поверх отлаженного happy path. Вот только все дедлайны к этому моменту, как правило, уже просраны, а релиз должен был быть позавчера. Купить время за деньги, увы, не получается.
Femistoklov
24.01.2026 00:29Купить время за деньги, увы, не получается.
Т.е. классическая "проблема 9 женщин". Наверняка должен быть "закон" имени какого-нибудь известного ПМ-а типа "качество ПО не зависит от бюджета организации".
Format-X22
24.01.2026 00:29Вот и получается у нас 15 действий по цепочке с одним обработчиком ошибок "что-то пошло не так!", либо вообще без обработчиков.
Забавно, но когда-то именно это считалось причиной победы Linux. В других уже умерших коммерческих ОС облепляли всё на свете проверками на ошибки, тратили много времени и денег. А в Linux был kernel panic. Сейчас про это уже забыли.
JBFW Автор
24.01.2026 00:29В Линуксе в цепочке cat xx | grep ddd |awk | sed | tail | blaablaba каждая отдельная программа способна:
1 - писать не только в stdout, но и в stderr
2 - завершать своё исполнение с кодом ошибкиВместе это создает прекрасную возможность отслеживания ошибок на каждой конкретной стадии, а если нельзя предусмотреть их заранее (например, возможно отсутствие строки для grep) - то условные операторы и код завершения помогут проблему купировать.
Какой еще kernel panic и причем он тут?!
0xC0CAC01A
24.01.2026 00:29А почему нельзя, наконец, сделать лимит на пожирание памяти джаваскриптом в браузере? Ах да, кажется, тогда gmail.com первым перестанет работать.
duselguy
24.01.2026 00:29Размер памяти в Хроме на десктопе в винде задавался параметром при его старте (не знаю, как сейчас). И я им пользовался (в сторону увеличения (для хранения больших таблиц в js)).
0xC0CAC01A
24.01.2026 00:29Если Вы про -Sv, то почему-то это не помогает, появляются процессы/табы, кушающие больше позволенного
duselguy
24.01.2026 00:29У меня (и других пользователей) проблем не было, может потому, что браузер работал офлайн с одним табом.
И это был SPA = мой код + datatables
Arioch
24.01.2026 00:29как его могли написать программисты, которые «знали о возможном наступлении проблемы, но самонадеянно полагали ее избежать»?
Ответ: только он и может существовать. Потому что программист должен сделать быстро и дешево. Или его уволят. Программист, который придёт к хозяину со словами "я хочу потратить на программу в 5 раз больше времени и вытащить из вашего кошелька в 5 раз больше зарплаты сегодня, потому что может быть где-то в Сомали через пару лет кто-то обкурится и начнёт отстреливать каждый шестой пакет" рисует себе на спине большую такую мишень. Сегодня рисует, а не через 5 лет.
Если вам интереснее подробнее и с примерами - просто прочитайте "The rise of worser is better"
Daddy_Cool
24.01.2026 00:29Что-то я не пойму.
Даже ИИ при упоминания malloc СРАЗУ ЖЕ выдаетarr = (int*)malloc(n*sizeof(int)); // Приведение типа к (int*)if (arr == NULL) { //Обязательная проверка на NULLprintf("Не удалось выделить память\n");...А вообще-то статья является переформулировкой закона Мёрфи.
«Если есть вероятность того, что какая-нибудь неприятность может случиться, то она обязательно произойдет».
https://old.mista.ru/merfy/index.html
ALT0105
24.01.2026 00:29Оно обязательно сломается, нужно просто рассчитывать на это заранее и немного подстраховаться.
От всего подстраховаться невозможно - в одних случаях элементарно не хватит денег, в других - невозможно в принципе, например, от конца света (землетрясение, астероид, третья мировая и т.д.). Вопрос в правильной оценке вероятности поломки и расчете объема ресурсов, которые можно выделить на ее предотвращение. Например, при разработке радиолокационных систем устанавливают разные вероятности пропуска цели и ложного обнаружения. И никто не требует достижения нулевых значений.
OldFashionedEngineer
24.01.2026 00:29Есть понятие условий эксплуатации. Если блок питания рассчитан на работу в однофазной сети - это значит, что кто-то другой обязан обеспечить ему параметры этой однофазной сети. Но, конечно же, общее разгильдяйство никто не отменял.
DartfoL
Не хватит, амплитудное значение напряжения в розетке - 325 В (при 230 В номинальных)
420AmonRa
Проверьте осциллографом. Вы удивитесь. Полная амплитуда намного больше.
KbRadar
Амплитуда - максимальное отклонение от среднего, не надо путать с "размахом". Да, сеть можно выпрямить с удвоением и будет 600+, но обычно так не делают.
420AmonRa
Не от среднего, а от точки равновесия. И да, я имел ввиду размах. Ошибся.
Tiriet
поэтому кондеры на 250В можно пользоваться в католических сетях 110AC, а в православных- надо брать конедеры на 400V. и перед ними ставить еще цепь безопасности, разрядник там, с плавкой вставкой, или еще какой элемент, чтоб снизить вероятность смерти оборудования от случайно клинанувшего в соседней стене промышленного перфоратора. А я как-то выносил технику из офиса, у которого на этаже клинанул такой перфоратор- половина входных цепей погорела, компы, МФУшки, принтеры. Было забавно- весь этаж небольшого офисного здания- комнат двенадцать- выносили сгоревшее офисное железо, включая даже один холодильник.
MaFrance351
И, по-хорошему, ещё неплохо ставить реле напряжения (а там, где известно, что оно и так нестабильное, и вовсе обязательно). Стоимость типичного экземпляра обычно вдесятеро окупается после первого же его срабатывания.