Механизм TRY_CATCH в CODESYS V3

Доброго времени суток, уважаемые форумчане.

Прошу поделиться своим опытом использования механизма TRY_CATCH (операторы __TRY, __CATCH) в CODESYS V3.

Почему заинтересовался этим вопросом?
За уже почти 20 лет работы программистом в области АСУ ТП, еще их не использовал ни разу в реальных проектах.
С другой стороны механизм реализован в CODESYS. Механизм призван повысить надежность программного кода, т.е. в том месте, где при ошибке программиста будет WatchDog или останов программы по исключению, при его использовании должно все продолжать работать, а в логах будет сообщение об ошибке.

Материала по данной теме для стандарта МЭК 61131-3 довольно мало. Вот что нашел и прочел:
1. Справка CODESYS
2. Статья Стефана Хеннекена: https://stefanhenneken.net/2019/07/2...__try-__catch/
3. Статьи для других языков

Везде объясняется синтаксис и базовые способы использования. Нигде нет толковых примеров, которые давали бы понять в какой момент нужно использовать TRY_CATCH, а где это не нужно, избыточно. Не использовать же __TRY для вызова любой функции/ФБ?

Вот пару собственных соображений/размышлений на этот счет:
1. Классический пример деления на ноль. Попробовал. Да, работает, в журнале вижу сообщение о таком исключении. Но я всегда просто проверял знаменатель на "не равен нулю".
В чем тут принципиальная разница мне не ясно!
2. Работал с библиотекой "CAA Net Base Services". Библиотека содержит ФБ для работы с сокетами. В частности блок TCP_Client открывает сокет и устанавливает соединение с удаленным сервером. Возвращает указатель на соединение (hConnection), который нужно передавать в блоки TCP_Write и TCP_Read. Решил попробовать, в секции __TRY вызвать TCP_Write и передать на вход нулевой указатель. В результате блок TCP_Write выдал на своем выходе ошибку 6003, а в секцию __CATCH не попадал, т.е. ошибка обработана внутри блока TCP_Write (что логично).
Получается, что использование для вызова блока TCP_Write/TCP_read механизма TRY_CATCH не нужно!
3. Наткнулся на ситуацию, когда при использовании __TRY все равно система зависла, хотя в журнале видно, что механизм отработал и мы попадали в секцию CATCH: https://owen.ru/forum/showthread.php...534#post479534


Буду благодарен за советы и соображения!
Спасибо!

Добрый день.

Цитата:

---

при его использовании должно все продолжать работать

---

Должно кому? В том смысле - кто это вам обещал?

Цитата:

---

Сообщение от Евгений Кислов

Должно кому? В том смысле - кто это вам обещал?

---

В справке CODESYS V3 моя мысль выражена фразой: "...приложение выполняет последующие операторы".
Вложение 87965

Евгений, Вы же понимаете, что вопрос не об этом?

Но, я еще раз поясню суть вопроса.

Пока я вижу ситуацию так.
В каких-то случаях (пример №1 из первого поста) использование не нужно, так как можно и без механизма TRY/CATCH выполнить программу так, что не будет исключения при выполнении. Или другими словами, если человек не чувствует, что нужно проверить знаменатель на не равенство нулю, то он и механизм TRY/CATCH не решит использовать в этой ситуации.
В других случаях (пример №2) использование излишне, так как разработчик используемого ФБ уже корректно обработал исключения внутри своих блоков и при их использовании не поймать исключение.
И, наконец, если разработчик системного блока совершил ошибку (пример №3), то программа все равно упадет. Подозреваю, что в рассмотренном примере происходит порча памяти где-то внутри CODESYS. Поэтому в момент, когда мой оператор совершает некорректное действие в операторе TRY система не падает, но потом, при первом же обращении к системному журналу уже других служб, происходит падение. Т.е. не от моей программы непосредственно, а "системно". Тут стоит заметить, что в журнале все же останутся какие-то следы, т.е. что вот попадали в секцию CATCH до этого. Т.е. будет над чем поразмышлять. Поэтому для 3го примера все равно следует признать, что есть смысл использовать этот механизм!

Поэтому и интересует опыт использования механизма TRY/CATCH.
Вероятно, приведенные мною примеры скудны и не отражают всю глубину механизма.
Буду рад, если другие приведут примеры использования, когда он, действительно, целесообразен.
И, конечно, хотелось бы понять критерий для рационального использования.

Спасибо.

Цитата:

---

Сообщение от Спорягин Кирилл

В справке CODESYS V3 моя мысль выражена фразой: "...приложение выполняет последующие операторы".
Вложение 87965

Евгений, Вы же понимаете, что вопрос не об этом?

---

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

Но это не равно формулировке "при его (__TRY) использовании должно все продолжать работать".

Во-первых, исключение может быть просто не детектировано. Вы как раз это наблюдаете в экспериментах с CMRemoveComponent.

Во-вторых, в реальном мире исключения в программе ПЛК, как показывает мой опыт, это обычно RTSEXCPT_ACCESS_VIOLATION или что-то аналогичное.
"Обработать" их в __CATCH не получится - память уже испорчена.
Максимум - можно попытаться освободить ресурсы (например, закрыть файл) - но и тут вам никто не даст гарантии, что это пройдет успешно.
Сообщение в лог в этом случае CODESYS выведет.

Цитата:

---

Поэтому для 3го примера все равно следует признать, что есть смысл использовать этот механизм!

---

Или можно просто добавить проверку на то, что удаляемый компонент действительно имеет смысл удалять.

Цитата:

---

так как разработчик используемого ФБ уже корректно обработал исключения внутри своих блоков]

---

И, скорее всего, сделал это без __TRY - а обычным сравнением указателя/размера буфера/дескриптора с нулем и т. п.

***
С вашем мнением по ситуациям с примерами 1 и 2 - согласен.

по мимо обработки ошибок можно внутри блока самому вызвать исключение, так по крайней мере в других ЯП, что например полезно при отладке знать по логам в какое время какой этап программы прошли, будет похоже на механизм точек останова, только без останова

Цитата:

---

например полезно при отладке знать по логам в какое время какой этап программы прошли

---

В подобных ситуациях можно просто вывести сообщение в лог - с помощью библиотеки CmpLog.