Я уже столько раз высказывался на эту тему и у себя в блоге (например), и на различных профильных форумах, что уже больше не вижу смысла даже и пытаться. Напрасная трата сил и времени. Особенно на ресурсах типа RSDN/LOR/Habr, где мне обязательно выскажут, что:
- программировать не умею;
- сделал образцовое нинужно и слишком много о себе возомнил;
- отставший от жизни старпер, доживающий свое в тесном манямирке из инструментов, которыми никто не пользуется.
Так что гори оно все огнем. Не буду больше никого ничему учить, лучше уж по стариковски побрюзжу в своем уютненьком. Это гораздо дешевле, чем в очередной раз растекаться мыслею по древу в рассказах про exception safety.
C++ заслужил того, чтобы сдохнуть в муках вместе со своим комьюнити. Если C++ники готовы жрать CMake и убивать приложения из-за std::bad_alloc, то на что вообще надеятся?
PS. Я не утверждаю, что любой std::bad_alloc можно пережить. Но ронять весь процесс из-за любого std::bad_alloc -- это не от большого ума. Такщитаю.
4 комментария:
Тут ведь как, никто ни хочет головой думать, ибо это черевато тем, что если вы ошибётесь, то вас съедят вместе с содержимым. Быть белой вороной опасно. Есть какие-то тренды, вот все им и следуют, так безопаснее. Если начальство не прикажет исправлять все эти падения от bad_alloc, то никто и не почешется. Я помню в одной фирме просто написали скрипт, который по таймауту поднимал упавший сервер, вместо того, чтобы разбираться почему он упал, благо данные при этом не терялись, а вы говорите bad_alloc обрабатывать ;)
> написали скрипт, который по таймауту поднимал упавший сервер
Так в том же Erlang-е этот принцип возведен в один из краеугольных камней: let it crash и supervisor tree с рестартами. Так что подход вполне себе разумный.
Более того, по моим впечатлениям, как раз в server-side толерантность к падениям при bad_alloc или чем-то подобном очень высокая. Все равно рано или поздно софт нужно обновлять, не всегда для этого специальные процедуры с плавным переводом нагрузки на новые сервера используются. Часто просто останов-обновление-рестарт. А уж рестарт из-за обновления или рестарт из-за bad_alloc -- какая разница? ;)
Еще вспоминается пример с паттерном Disruptor от Lmax (если мне не изменяет склероз). Там же люди изначально намеренно пошли на то, что GC отключали совсем, чтобы с его задержками не бороться. Просто раз в сутки софт перезапускали и все. GC смогли нормально победить только спустя год или два эксплуатации.
> Так что подход вполне себе разумный.
Таки да. Но есть и обратная сторона медали, таким образом разработчики, как бы, снимают с себя ответственность и это входит в привычку. А так как других разработчиков у нас нет, то советуют всем привыкнуть к падучему и лагучему софту. Похоже положить конец этому делу смогут только когда программистов начнут заменять нейросетями ;)
> когда программистов начнут заменять нейросетями ;)
Да вроде бы уже и недолго осталось. Вот-вот :)
Отправить комментарий