View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002010 | SAS.Планета | Рефакторинг / Refactoring | public | 09-07-2013 16:43 | 09-07-2013 18:50 |
| Reporter | zed | Assigned To | zed | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 121010 | ||||
| Target Version | 131111 | Fixed in Version | 131111 | ||
| Summary | 0002010: Обработка ошибок в TThreadRegionProcessAbstract и TThreadCacheManagerAbstract | ||||
| Description | В этом потоке и всех его наследниках (операции с выделенной областью) зачем-то поставлен перехват исключений и ручной вывод сообщений через MessageBox. И это по-моему не верно и нужно разрешить исключениям всплывать на самый верх, дабы Эврика могла сгенерировать правильное сообщение. | ||||
| Tags | No tags attached. | ||||
|
|
Перехват исключений из рабочих потоков надо оставить, но скидывать их в очередь, а в основном потоке по таймауту нюхать эту очередь и генерить исключения из неё (можно одно на всю пачку, если все данные будут в это одно падать). |
|
|
Зачем? И ты уверен, что сгенерированное исключение будет сколь-нибудь полезнее того месседж-бокса? В смысле стек вызовов и прочее, как ты через очередь и ручное генерирование пробросишь? |
|
|
Какая-то обработка ошибок должна быть для недебажной версии. Но даже для дренажной, я не уверен, что мы хотим чтобы программа полностью падала при ошибке экспорта. |
|
|
>Зачем? Затем, что самые простые грабли из существующих - это raise из потока. Проще только объкты передавать по ссылке между хостом и DLL. Ну то есть оно конечно работать может быть даже и будет, но шаг вправо или шаг влево - расстрел всей программы. >как ты через очередь и ручное генерирование пробросишь? Нет ничего проще. Обычный TList с критической секцией (спин-лок), куда можно кидать ЛЮБЫЕ объекты, писатели кладут туда готовый объект, а читатель просто тащит оттуда всё что может и raise-ит объект (raise работает не только для исключений). То есть в общем случае, что сгенеришь в потоке, то и вылетит в основной. Если не выделываться и ограничиться Exception-ами, то от них ClassName+Message в первом приближении более чем достаточно (и уж явно не хуже MessageBox-а), тогда можно будет свалить все исключения из очереди в один большой кумулятивный raise. Наверняк нечто подообное уже есть в сасе, надо только поток нюхателя прикрутить и прокинуть эту очередь в рабочие потоки. Или я чё-то не так понял? |
|
|
В идеале конечно хотелось бы в рабочем потоке перехватить исключение, отдать его Эврике, получить от неё результат (со стеком и т.п.), а в основной поток пропихнуть нечто минимально необходимое для реакции пользователя, например ClassName + Message + имя файла, куда результат работы Эврики слился. |
|
|
>я не уверен, что мы хотим чтобы программа полностью падала при ошибке экспорта Почему программа полностью? Мне казалось, что вылететь должен только один поток. >ClassName+Message в первом приближении более чем достаточно В том то и дело, что мало. Нужен стек вызовов. |
|
|
>казалось, что вылететь должен только один поток Один поток вылетает гарантировано. Остальное - как повезёт. >Нужен стек вызовов Мы можем попросить Эврику дать нам всю нужную инфу при перехвате исключения в рабочем потоке? |
|
|
>В идеале конечно хотелось бы в рабочем потоке перехватить исключение, отдать его Эврике, получить от неё результат Хм, а вот тут надо подумать и почитать маны по Эврике, возможно что-то и получится. |
|
|
>Почему программа полностью? Мне казалось, что вылететь должен только один поток. Я думал, что если исключение добралось до эврики то она должна создать елф-файли и закрыть всю программу. |
|
|
Не, Эврика сама по себе ничего не закрывает. Она только логи пишет. Но в окошке с ошибкой есть галочка Terminate, по которой может и прибить приложение. В общем, добавил пару строчек и теперь Эврика будет обрабатывать ошибки своими методами. При этом, насколько я понимаю, рабочий поток будет завершаться в штатном порядке, аналогично случаю с месседж-боксом. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 09-07-2013 16:43 | zed | New Issue | |
| 09-07-2013 16:48 | vasketsov | Note Added: 0012031 | |
| 09-07-2013 16:53 | zed | Note Added: 0012032 | |
| 09-07-2013 17:13 | vdemidov | Note Added: 0012033 | |
| 09-07-2013 17:15 | vasketsov | Note Added: 0012034 | |
| 09-07-2013 17:20 | vasketsov | Note Added: 0012035 | |
| 09-07-2013 17:20 | zed | Note Added: 0012036 | |
| 09-07-2013 17:23 | vasketsov | Note Added: 0012037 | |
| 09-07-2013 17:26 | zed | Note Added: 0012038 | |
| 09-07-2013 18:35 | vdemidov | Note Added: 0012039 | |
| 09-07-2013 18:45 | zed | Note Added: 0012040 | |
| 09-07-2013 18:49 | zed | Status | new => resolved |
| 09-07-2013 18:49 | zed | Fixed in Version | => 131111 |
| 09-07-2013 18:49 | zed | Resolution | open => fixed |
| 09-07-2013 18:49 | zed | Assigned To | => zed |
| 09-07-2013 18:50 | zed | Target Version | => 131111 |
| 09-07-2013 18:50 | zed | Summary | Обработка ошибок в TThreadRegionProcessAbstract => Обработка ошибок в TThreadRegionProcessAbstract и TThreadCacheManagerAbstract |
| 09-07-2013 18:56 | zed | Relationship added | related to 0001943 |
| 08-08-2025 13:25 | zed | Category | Рефакторинг => Рефакторинг / Refactoring |