Доброго времени суток, уважаемые:
от слов к коду.
есть поток:


В обработчике таймера:


Периодически (пользуюсь MadExcept) "наружу" вылезает исключение EArgumentOutOfRangeException, т.е. на экране появляется окошко MadExcept-ов с кнопочками "продолжить, перезапустить..."

Вопрос:
почему оно, это окошко, вылезает? Ведь обработка WM_TIMER обернута в try-except, соответственно - исключение должно записаться в лог и уйти на следующий виток while.
Чего я не понимаю и что делаю не так?

Вылезает всегда или только во время работы из-под IDE?

Вылезает не всегда (имеется ввиду - не на каждом вызове события таймера), но при работе из-под IDE, как ни старался, отловить не удалось.
P.S. Используется стандартный TTimer.
Причину возникновения EArgumentOutOfRangeException я уже отловил и устранил, но - с чего оно вылезло за except-блок?

UPD. Нашел, в чем дело. Исходный код оконной процедуры Ttimer:


Это сообщение отредактировал(а) kami - 14.10.2013, 12:40

По твоему коду непонятно, где именно.
Если окно с сообщением об исключении вываливается при работе аппликации из-под IDE (отладчика), то это нормально.

Если вываливается сообщение самого IDE (там, где есть чекбокс "игнорировать в будущем") - да, это нормально. Но оно останавливает работу потока в "боевом" режиме, не из-под IDE.



Я привел не полный код? Вроде, весь, относящийся к делу (пост №1):
в потоке создана очередь сообщений, которые вылавливаются в цикле. Каждая итерация цикла заключена в try-except. 
Приходит сообщение WM_TIMER, оно через DispatchMessage и оконную процедуру таймера попадает в обработчик OnTimer, там возбуждается исключение, но оно не "гасится" в except-блоке цикла обработки сообщений, хотя - должно.

В принципе, причина выяснена - оконная процедура TTimer самостоятельно вызывает Application.HandleException (кто б ее об этом еще просил).
Осталось выяснить - как с этим бороться. Единственное, что приходит в голову - каждый обработчик OnTimer нужно заключать в try-except, что мне совсем не улыбается.

Кстати, в этом случае получается, что я не могу передать возбужденное в OnTimer исключение "вверх" на уровень... Плохо...

Upd.
Либо - хватать Application.OnException и там... - re-raise что ли, но это вообще не нескафе...

Это сообщение отредактировал(а) kami - 14.10.2013, 20:26

  Делфя старается перехватывать все исключения в главном потоке. TTimer это компонент. Как известно, в делфях предполагается, что компоненты работают в главном потоке. В данном случае проще свой класс таймера написать. Тем более что там 3.5 строчки кода.

Этот ответ добавлен с нового Винграда - http://vingrad.com

Создай поток с событием, в котором будет срабатывать процедура через определённые интервалы времени.

Если что, у меня есть готовый пример.

Это понятно. Однако, исключение и так будет перехвачено в Application.Run, в цикле обработки сообщений (да, в предыдущих сообщениях неправильно написал - ProcessMessages, по крайней мере в D2010, не ограждено try-except). На кой нужен прямой вызов HandleException из оконной процедуры таймера - так и не понял.
В общем и целом - вопрос решен:




Было бы неплохо, т.к. не понимаю, как это - 

где-нибудь в приложении, например,  в главной форме 



если нужно вызвать thread.execute принудительно, не дожидаясь, пока таймер сработает, можно вызвать в любой момент:

https://www.google.com/search?q=thread+Wait...tbs=lr:lang_1ru

Понятно. Мне больше бы подошло RegisterWaitForSingleObject, с которым так и недопереразобрался. Тормозить очередь сообщений на WaitFor - не комильфо.
Спасибо.

не понял

Добавлено через 23 секунды
А я думал, что это самый правильный подход.

Добавлено через 1 минуту и 13 секунд
вот ещё посмотри http://www.sql.ru/forum/1050286/shablon-kl...-wthread-thread

Если (как, допустим, в примере) ставить в WaitFor dwMilliseconds = 1000, то получается, что ни одно окно (из числа созданных в этом потоке) целую секунду не сможет получить ни одного сообщения.

так тебе говорят про отдельный поток, в котором нет гуя