По поводу надежности ПО. Exception handling = must have
При обнаружении критической ошибки MQL5 скрипт снимается с исполнения терминалом.
Фактически нельзя оставлять работать программу, которая крешится. Это означает, что не имеет смысла даже сообщать самому скрипту об этом - все равно он ничего не сможет сделать, а скорее всего сгенерирует новые креши.
Выход для экспертописателей только один - максимально полно тестировать свои программы.
- www.mql5.com
...
Сейчас сильно напрягает ситуация, когда весь терминал падает из-за DLL.
....
В механизме перехвата/обработки креша из dll был косяк, который и приводил к падению терминала. Он исправлен, ждите обновлений.
Теперь, из-за ошибок dll (если dll сама не закроет процесс при креше) терминал "валиться" не будет.
Однако вы не сможете программно обработать данный креш - эксперт, после вывода сообщения в лог, "жёстко" выгрузится (без вызова деструкторов и OnDeinit()).
При обнаружении критической ошибки MQL5 скрипт снимается с исполнения терминалом.
Фактически нельзя оставлять работать программу, которая крешится. Это означает, что не имеет смысла даже сообщать самому скрипту об этом - все равно он ничего не сможет сделать, а скорее всего сгенерирует новые креши.
Выход для экспертописателей только один - максимально полно тестировать свои программы.
Господа! Странно это все слышать. Технология обработки исключительных ситуаций как раз предназначена, чтобы перехватывать падения и дать возможность программе урегулировать ситуацию.
Я не говорил, что программу, которая упала, нужно оставлять выполняться, а лишь утверждаю, что неплохо бы предоставить прикладные средства обработки ошибок, после которых возможно не прийдется прерывать исполнение. Не все падения критические. Предоставьте программеру самому решать, какие ситуации как разруливать. Если конкретный "экспертописатель" не создаст обработчика исключительных ситуаций или пропустит исключение, то вы остановите его скрипт по нынешней схеме.
Протестировать скрипт на практически любых сочетаниях входных данных - нереально. Скрипты работают с потоком котировок, который бесконечен в своем многообразии. Поэтому от получения непредвиденных значений в расчетах никто не застрахован. Но как можно будет проанализировать и исправить ошибку, если вы не предоставляете такой возможности и открытым текстом декларируете, что в этом случае лучше молча прибить скрипт?!
Выход правильный - действительно один: поддержать механизм исключений в скриптах. Если бы Вы ответили, что это у в планах, но пока не реализовано, то я б воспринял это с пониманием. Но ответ с такой аргументацией - "не имеет смысла" и "нельзя" - разочаровывает. Это уже не первый случай, когда ваши решения, мягко говоря, вызывают сомнения в вашей компетенции как разработчиков софта.
Господа! Странно это все слышать. Технология обработки исключительных ситуаций как раз предназначена, чтобы перехватывать падения и дать возможность программе урегулировать ситуацию.
Во многих случаях можно обойтись без исключений, заменяя их явными проверками и использованием кодов возврата. А ещё обработка исключений по идее выполняется гораздо медленнее, чем простая проверка некоторых условий (если возможно их сформулировать) - при написании экспертов скорость важна.
Во многих случаях можно обойтись без исключений, заменяя их явными проверками и использованием кодов возврата. А ещё обработка исключений по идее выполняется гораздо медленнее, чем простая проверка некоторых условий (если возможно их сформулировать) - при написании экспертов скорость важна.
Во всех контролируемых нами случаях мы обходимся без исключений. Но вот контролировать сторонние dll мы не можем. Поэтому при вызове dll-функции мы вынуждены использовать механизм исключений.
У MQL5 программ нет механизмов Exception Handling.
То есть, эксепшены не генерятся. Вместо этого есть классический метод проверки кодов возврата.
Сам язык полностью managed, что означает полный контроль со стороны среды исполнения над кодом. Если в такой ситуации сгенерировалась критическая ошибка, то можно закрывать работу этого скрипта.
Проконтролировать деления на ноль и выходы за пределы массивов должен сам программист, если не хочет, чтобы его программу остановили.
Благо, что подсказки очень точные:
- www.mql5.com
Вообще конечно смешно через эксепшены ловить деления на ноль в своих программах, а потом как ни в чем не бывало пытаться продолжать работать...
И ведь ловят!
Во многих случаях можно обойтись без исключений, заменяя их явными проверками и использованием кодов возврата. А ещё обработка исключений по идее выполняется гораздо медленнее, чем простая проверка некоторых условий (если возможно их сформулировать) - при написании экспертов скорость важна.
Опять же, не однозначно это всё. Где то эксепшены удобнее и органичнее, где то явные проверки гораздо лучше смотрятся. В итоге, ни тот, ни другой метод не имеет подавляющего превосходства. А в семёрке вроде бы вообще внутренний механизм эксепшенов поменялся, говорят.
Вообще конечно смешно через эксепшены ловить деления на ноль в своих программах, а потом как ни в чем не бывало пытаться продолжать работать...
И ведь ловят!
Иногда эксепшены используют как часть алгоритма. Сразу же скажу, что сам я так не делаю, но видел такое.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Просветите плиз про пятерку в плане обработки исключений. Всё же это софт, непосредственно оперирующий деньгами. В четверке, если произошла скриптовая ошибка (деление на ноль, в частности), исполнение прерывается и в результате вполне может случиться убыток. Я не нашел в документации ничего про ошибки, за исключением рудиментарной функции GetLastError().
И еще хотелось бы выяснить схему работы с плагинами в пятерке. Сейчас сильно напрягает ситуация, когда весь терминал падает из-за DLL. Может быть имеет смысл проработать какой-нибудь иной принцип - типа грузить сторонние dll-и не в процесс терминала, а в пулы приложений - отдельные экзешники?