On Tue, Oct 04, 2022 at 11:33:14PM +0700, Eugene Grosbein wrote: > 04.10.2022 20:11, Evgeniy Berdnikov пишет: > > При потенциальной возможности зануления указателя следует ловить и > > обрабатывать такое исключение. В противном случае нет смысла в проверке. > > Задача же не в ублажении тупых анализаторов, а в правильной работе кода. > > Как пользователь разнообразного софта, могу доложить, что сегфолт очень > фиговая обработка исключений. > Проверка указателя на NULL перед разадресацией в том случае, когда нельзя > гарантировать что он не NULL, > практически всегда благо.
Ну, я написал что такую ситуацию нужно ловить всегда, т.е. MUST а не SHOULD. > Другой вопрос, что потом делать, если вдруг: молча восстановиться и ехать > дальше, > или не молча, а с сообщением в лог, или выдать даже stack trace и выйти. Но > что угодно лучше сырого сегфолта. Был бы я пользователем, я бы тоже так считал, наверное... Но поскольку я сисадмин с некоторым запилом в разработку, то думаю иначе: вставить в свою софтину полноценный обработчик сегфолта, с анализатором стека и печатью регистров, чтобы по функционалу всё было не хуже gdb -- это очень непросто. Корпорации размера Оракл могут себе такое позволить, и нанять кучу фултайм-саппортеров на разборку трейсов, а для широкой публики нет ничего эффективней сборки без стрипа -> coredump -> gdb -> "bt full" и анализа содержимого регистров, памяти, etc. Конечно, если софтина mission critical, и останавливаться ей никак нельзя, то нужно думать об обработке сбоев. Но в большинстве случаев это можно решить дизайном: например, при сегфолте в рабочем процессе автоматически запускать новый, отмечать сбой в логе / e-mail, а корку оставлять админу на изучение. -- Eugene Berdnikov _______________________________________________ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org