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-leave@nginx.org