Я вот одного не пойму, ну зачем было описывать процедуру как of object... чтобы к какому нибудь объекту прицеплять?... По-моему было бы лучше простую процедуру... ну да ладно.
of object потому, что это общепринятое объявление для методов класса. От обычного процедурного типа отличается тем, что при его вызове будет передаваться скрытый параметр self, указывающий на экземпляр класса, который производит вызов.
Кстати, при этом вовсе не обязательно перекрывать класс TApplication. Можете объявить соответсвующий метод в любом из классов, хоть в той же главной форме приложения, а потом подставить его вместо Application.OnException.
При этом "правила хорошего тона" предполагают, что указатель на старый метод сохраняется внутри вашего класса и он вызывается во всех тех случаях, которые вы сами не обрабатываете.
Это довольно удобная штука, однако в приложениях более менее требующих фирменного стиля, эти окна сразу бросаются в глаза, не говоря уж о том, что во многих случаях удобнее было бы обрабатывать исключения полностью вручную и возможно без уведомления пользователя окнами.
Если вы пишите "фирменное приложение", то по большому счёту в нем сообщения об ошибках у пользователя вообще возникать не должны. А те сообщения об исключительных ситуациях, вызыванных либо его действиями, либо дествиями других программ или ОС должны быть вами обработаны и вы как разработчик должны решить, что в этом случае следует делать. то ли спрашивать пользователя, то ли самому как-то обходить поблему. По большому счёту встроенные окна сообщений расчитаны именно на разработчиков для режима отладки.
Лично на мой взгляд для решения данных проблем возможностей конструкции try\except\finally хватает на 95%. Другое дело, что сложность разработки "защищённой" программы при этом возрастает в разы. Ну так тем действительно фирменная программа и отличается от кустарной поделки.
А вот другой случай:
Библиотека каким то образом запортит данные программы, что чаще всего и бывает с самыми труднообнаружимыми ошибками... Цикл благополучно отработает. Спустя некоторое время начнёт выполняться код с данными, которые никто в try сажать не будет, и вот тут то и случится непредвиденное...
Да уж, подобные проблемы с dll вегда сложно отлавливать. Но тут уж либо не использовать библиотек, которые портят данные программы, либо втсраивать в программу защитные механизмы, чтобы она могла обнаружить, что данные были испорчены. Именно по этой причине в тех местах, где это не слишком обременительно или очень важно я всегда проверяю корректность входных данных, чтобы программа лишний раз не показывала пользователям сообщения, в которых он всё равно ни черта не поймёт.
А с дрйго стороны, подобное поведение библиотеки возможно либо если она плохо отлажена (не используйте подобные библиотеки), либо вы сами подали ей на вход не совсем корректные данные (нужно внимательнее читать документацию к библитекам и тщательнее проверять корректность передаваемых данных). Причём мой личный опыт говорит о том, что второй вариант встречается всё таки гораздо чаще, чем первый.
