TThread и обработка исключений

← →
Тимохов © (2004-04-15 10:47) [0]

Уважаемые мастера.

Задача: при возникновении исключения в потоке показать его в форме (добавить в Memo.lines).

Решения два.

1. Обрамить все содержимое execute в try except и в случае впозникновения ислючения не прерывать работу execute но через synchronize передать исключение главному потоку, чтобы он добавил текст исключения в memo. Достоинством является то, что поток не помирает после исключения.

2. Считать, что исключение возникшее в потоке явлется критичным (т.е. приводящим к остановке потока) и добавлять текст в memo в onTerminate потока без всяких исключений проверяя FatalException.
Недостатком является то, что поток помирает после исключения.

Вопрос, какой метод более верный?

ЗЫ Данный вопрос несет познавательные цели, поэтому предлагать в корне иной метод не стоит.

← →
Romkin © (2004-04-15 10:50) [1]

Если не ошибаюсь, если поток создается через BeginTread, то обработка исключений уже встроена, и ничего делать не надо.

← →
Romkin © (2004-04-15 10:51) [2]

И что значит, какой подход более верный? Как надо, так и делай. Вообще говоря, хорошим тоном является, когда исключение прерывает работу процедуры :)

← →
Тимохов © (2004-04-15 10:53) [3]

> Romkin © (15.04.04 10:51) [2]

"ВЕрный" синоним "методологически верный".
На такие вопросы всегда очень позновательно Юрий Зотов отвечает - знаток корректных методик.

Что значит встроено? Все, что сделано, это то, что образуется FatalException если возникает необработанное исключение. Вроде там большие ничего нет.

← →
Digitman © (2004-04-15 10:56) [4]

считать или не считать факт возникновения искл.ситуации в потоке критическим - решать только тебе ... для этого в except-блоке, очевидно, следует проанализировать класс и атрибуты объекта-исключения и уже на основе анализа принимать решение о возможности или невозможности дальнейшей работы потока, о необходимости (или отсутствии таковой) регистрировать искл-е с пом. того или иного механизма протоколирования ..

если таки возникла необх-ть протоколирования, то Synchronize вовсе не панацея .. можно, к примеру, воспользоваться обычным PostMessage(), подобно тому как это сделано, например, в методе TTransportThread.Execute в модуле SConnect.pas .. загляни туда и разберись в этой идее, она не самая худшая ... там, кстати, как раз и реализован анализ искл.ситуации, по результатам которой транспортный поток либо закругляется немедленно либо шлет сообщение осн.потоку и продолжает работать

← →
TUser © (2004-04-15 10:59) [5]

Не мне вам советовать, но я думаю, что каждый из этих методов имеет свою область применения. Т.е. все определится тем, должен ли поток умереть после эксепшена. Наверное, для потоков, которые делают какие-либо расчеты предпочтительнее будет убивать их (все равно дальнейшие расчеты скорее всего окажутся непраивльными). А если этот поток что-то мониторит, то он должен выжить.

← →
Тимохов © (2004-04-15 11:02) [6]

> Не мне вам советовать

почему? любой совет полезен.
Хоть и давно пишу в д - потоками пользовался всего несколько раз и то для некритичных задач. Опыта т.е. нет.

Digitman.
Спасибо за TTransportThread - очень позновательно.

Всем.
Главное, что я понял - тут нет правил и догм - поток должен выжить/умереть - все диктуется логикой приложения.

← →
Digitman © (2004-04-15 11:10) [7]

> тут нет правил и догм - поток должен выжить/умереть - все
> диктуется логикой приложения.

совершенно верно

← →
Romkin © (2004-04-15 11:13) [8]

SConnect & MConnect явно писал программист, помешанный на интерфейсах и объектах: интерфейсы порождают интерфейсы, которые обмениваются сообщениями в виде интерфейсов... Брр

Всем спасибо - очень позновательно.

> Romkin © (15.04.04 11:13) [8]

может быть и помешанный, но зерно разумного в том, что он там начудил, imho, есть)

к примеру, взяв на вооружение "навязанные" мне IDataBlock, ITransport, ISendDataBlock, мне достаточно легко удалось реализовать и подцепить ко всей этой петрушке собственные классы, ощутимо расширяющие возможности обмена между сервером и клиентом ... при этом всю окаймляющую (работающую с этими интерфейсами) транспортную ботву переделывать практически не пришлось - интерфейсы же я не менял, зато функциональность интерфейсных объектов легко подогнал под свои нужды

TThread и обработка исключений Найти похожие ветки