![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
nanomsg, zeromq и ассерты
Продолжаю вникать в легковесные MQ библиотеки и ужасаюсь одной всепроникающей идее - ассерты в релизном коде, буквально на каждый возможный косяк.
С одной стороны, fail-fast это правильный подход, пусть супервизор процессов разбирается что дальше делать.
С другой - abort или RaiseException на виндах кидают messagebox, а messagebox в виндосервисе, если нет чек-бокса "разрешить взаимодействие с десктопом", это гамон, такой процесс можно только убить, он больше не подчиняется указаниям от сервис-контроллера. То же самое - запуск процессов из task scheduler, этот мессаджбокс будет "где-то висеть" в гребенях сессии в которой запущены сервисы.
Далее, нормальная методика при обработке ошибок: try {} catch(exception) { log(сообщение, параметры вызова, exception);throw}. Т.е. я по крайней мере, по логам узнаю, что привело к исключению (за исключением совсем плохих вещей, типа полной нехватки памяти, умершего железа или выдернутого езернет-провода).
В случае же assert - у меня процесс сдыхает (и не дай бог в соседних потоках писать на диск или работать с железом), причем если супервизор, который может прочесть stderr и скопировать сообщение в свой лок,отсутствует - сообщение об ошибке уйдет в никуда.
Судя по тому, как друг на друга псят Martin Sustrik и Pieter Hintjens, отзывам про либы и тому бардаку, который творится в коде nanomsg(например, комментарий вида: /* For some reason simple CancelIo doesn't seem to work here. We have to use CancelIoEx instead. */ в коде, из-за которого nanomsg вообще не запускается на 2003 и xp), ситуация с этими либами откровенно нехорошая.
С одной стороны, fail-fast это правильный подход, пусть супервизор процессов разбирается что дальше делать.
С другой - abort или RaiseException на виндах кидают messagebox, а messagebox в виндосервисе, если нет чек-бокса "разрешить взаимодействие с десктопом", это гамон, такой процесс можно только убить, он больше не подчиняется указаниям от сервис-контроллера. То же самое - запуск процессов из task scheduler, этот мессаджбокс будет "где-то висеть" в гребенях сессии в которой запущены сервисы.
Далее, нормальная методика при обработке ошибок: try {} catch(exception) { log(сообщение, параметры вызова, exception);throw}. Т.е. я по крайней мере, по логам узнаю, что привело к исключению (за исключением совсем плохих вещей, типа полной нехватки памяти, умершего железа или выдернутого езернет-провода).
В случае же assert - у меня процесс сдыхает (и не дай бог в соседних потоках писать на диск или работать с железом), причем если супервизор, который может прочесть stderr и скопировать сообщение в свой лок,отсутствует - сообщение об ошибке уйдет в никуда.
Судя по тому, как друг на друга псят Martin Sustrik и Pieter Hintjens, отзывам про либы и тому бардаку, который творится в коде nanomsg(например, комментарий вида: /* For some reason simple CancelIo doesn't seem to work here. We have to use CancelIoEx instead. */ в коде, из-за которого nanomsg вообще не запускается на 2003 и xp), ситуация с этими либами откровенно нехорошая.
no subject
Вообще у мессаджбокса есть флажок MB_SERVICE_NOTIFICATION, но и с ним не всё гладко. Как и с функцией MessageBoxTimeout.
Сама идея взаимодействия с пользователем из процесса, с пользователем не связанного, без желания на то пользователя - бред и зло. Как следствие - не надо бросаться ассёртами из библиотек в релизе.
no subject
Если архитектура - говно, надо просто это признать и исправить, а не придумывать гнилые отмазки. Окошки с сообщениями имеют смысл только если их есть кому смотреть (a.k.a. интерактивный режим). За сервисом смотреть некому, за ним должен следить запускатор сервисов и писать в логи/слать письма-смс/звонить админу, если сервису стало плохо.
no subject
Но что касается assert - тут уже разработчики библиотеки упускают из виду, что он может разворачиваться особо умным компилятором в показ MessageBox() (в т.ч. из консольного приложения - встречал) и прочие гадости. Известные ведь грабли, проще написать свой макрос с предсказуемым действием, чем в сотый раз на них наступать.
Если что - я этот сами-знаете-какой-компилятор, разумеется, не оправдываю.
no subject
no subject
Впрочем, это уже холивор.
no subject
Оно, впрочем, на любые необработанные исключения вылазит, если SetErrorMode c флагом SEM_NOGPFAULTERRORBOX не вызвать.