-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Попытка не перехватывает вложенное исключение в фоновом методе #1495
Comments
@bolsun на всякий случай уведомляю тебя. Вдруг Турбоконф тут как то причастен. |
@sfaqer поясни, зачем ты добавил ОжидатьЗавершения(). У меня выполнение без синхронизации потоков. |
Потому что без ожидания потока основной поток (и всё приложение) завершается раньше чем завершится фоновый поток, и ты получишь то поведение что описал, это не ошибка это так работает |
Ты можешь это доказать проверкой моего теста? |
Спасибо. Это немного проливает свет на происходящее. Но в моем случае материнский процесс (Турбоконф) создает объект ОСкрипт и запускает в нем скрипт. Внутри выполнения скрипта запускается фоновый метод. Основной метод (поток) скрипта быстро завершается. Но объект ОСкрипт с выполняющимся фоновым методом продолжает жить и завершается только при завершении фонового метода. Вот проблема в том, что любое исключение, выброшенное в таком фоновом методе, уходит в никуда, т.е. не перехватывается попыткой. Видимо без разработчика Турбоконфа @bolsun не удастся до конца разобраться. Но пока я все же допускаю, что обработка исключения в этом сценарии выполняется некорректно в самом ОСкрипт. |
А можно ожидать завершения фз в основном потоке, запускаемым турбоконфом? Или это мешает процессу/логике работы турбоконфа? |
На минуту заморозить интерфейс Турбоконфа? Это будет жестоко. |
Повторюсь, что если исключение не выбрасывать, то все сигналы доходят. Например сообщения, которые Турбоконф из вывода ОСкрипта перенаправляет в свой журнал, еще уведомления всплывающие, записи в файл и т.д. Думаю проблема в выбросе исключения, который досрочно завершает поток, или в отлове выброшенного исключения конструкцией "Попытка", которая не срабатывает в этом сценарии. |
Я не знаю архитектуру турбоконфа, поэтому и спросил. Может там запуск оскрипта асинхронный, поэтому блокировки интерфейса бы не было. |
Закрываю, т.к. турбоконф-specific |
ТурбоКонф специфик или HostedScriptEngine специфик? |
Я не знаю как реализованы ФоновыеЗадания в OScript, но если взять по аналогии BackgroundWorker, то при возникновении исключения при его выполнении, оно тоже не будет вызвано в родительском процессе. Но для этого есть обработчик завершения выполнения, а в нем есть свойство Error. В котором содержится ошибка, если она была.
|
Таким образом IHostApplication вполне может иметь метод или событие, которое вызывается при ошибке в фоновомзадании. |
Поэтому может рановато закрывать? |
IHostApplication имеет метод для отображения инфы об ошибке неперехваченного исключения, но не уверен, что он вызывается менеджером ФЗ и вообще такой кейс с ФЗ кажется надо проектировать отдельно.
Конкретно эту стоит закрыть, а вот открыть еще одну с описанием пожелания получать в хост-приложении неперехваченные ошибки ФЗ имеет смысл. Но тогда все равно остается в зоне ответственности хост-приложения (турбоконфа) решение о том, что делать с полученной информацией. |
Актуально |
Я использую метод ShowExceptionInfo(Exception exc); Но он не вызывается при исключении в фоновом задании. |
У меня в ИР адаптере для Турбоконфа ключевая операция - подключение клиентского приложения ИР. Мы долго ее оттачивали, чтобы все возникающие при ее выполнении ошибки были видны пользователю. Ну и сами причины таких ошибок большинство устранили. Однако после перевода ее в фоновый режим пользователь перестал видеть эти ошибки. И хотя такие ошибки уже случаются довольно редко, все же пользователь в них оказывает слеп. Поэтому снова призываю всех, кто еще не проверил на своей стороне все возможности решить эту проблему, сделать это. |
Решил сам воспроизвести проблему и у меня все работает нормально.
|
Получается, что OScript пробрасывает исключение в HostApplication, а TurboConf также корректно это обрабатывает. |
Удалось выяснить, что если в внутри метода перехватывать исключение через Попытка Исключение КонецПопытки, то его можно обработать. Такой код уже не работает корректно
|
@bolsun выше #1495 (comment) уже разобрали что мне ФЗ.ОжидатьЗавершения() нельзя вызывать |
Это не при чем. В моем примере я использую ОжидатьЗавершения() и исключение обрабатывается. |
Вот без ожидания завершения.
|
Да. В таком чистом тесте не воспроизводится. Сделаю полный тест. |
Этот скрипт в среде Турбконф выводит сообщение "Ау1" и не выводит "Ау2" и не выбрасывает исключение. Входной метод - ЗапуститьПодключениеИР.
|
Дело даже не в пробрасывании исключения или текста ошибки в HostApplication.
|
@EvilBeaver пора переоткрывать заявку |
Тест от @bolsun воспроизводится в ванильном оскрипте? |
@EvilBeaver вот тест для чистого ОСкрипт 1.9
Результат подтвержден. Выводит сообщение "Ау1" и не выводит "Ау2" и не выбрасывает исключение. Похоже есть ошибка в управлении попытками в фоновом режиме выполнения кода. |
Cc @sfaqer |
@sfaqer однако поведение без фонового задания другое
Значит тут двойная ошибка в ОСкрипт. |
Нет тут другого поведения, фоновое задание не выбрасывает исключение by design у фонового задания есть свойство ИнформацияОбОшибке, в котором лежит информация о исключении возникшем внутри фонового задания. |
@sfaqer Согласен. |
Как гарантировать донесение необработанного в фоновом задании исключения до пользователя/журнала в случае, когда основная программа завершила работу (нет ожидания)? |
Переоткрываю, т.к. требует проектирования API исключений в ФЗ |
Куда наружу, если основной поток по твоим словам завершился? |
Версия ОСкрипт 1.9 (внутри Турбоконфа)
Выполняю фоново метод и выбрасываю в нем исключение и в попытке вывожу сообщение или любое другое сигнальное действие. Но сообщение (сигнал) не выводится и отладчик в секции "Исключение" не останавливается.
ФоновыеЗадания.Выполнить(ЭтотОбъект, "тест");
Этот тест выводит сообщение "Контроль1", но не "Ошибка".
Делаю вывод, что там что то сломано. Если будешь чинить, то большая просьба продублировать фикс в ветке 1.9
The text was updated successfully, but these errors were encountered: