No.
MQL4
не поддерживает синтаксис конструкции, аналогичной вариантам использования try/except/finally
или try/catch
в python/java и подобных языках.
Как обрабатывать исключения?
Предположим, что ошибок времени компиляции нет.
Ошибки времени выполнения трудно обработать, некоторые даже вызывают сбой программного обеспечения.
Можно и, скорее, нужно проактивно очищать MQL4-код с должной проверкой типов и предварительными проверками вариантов использования, чтобы предотвратить исключения.
Исключением являются операции dbPool
, которые при некоторых условиях могут "законно" не дать ожидаемого результата.
GetLastError()
(если оно было очищено априори само исключение) может служить почти посмертной идентификацией, а не обработчиком исключения.
4202? Не твоя проблема, бро
_LastError == 4202 ... does not explain the trouble <<< stdlib.mqh
4202
ERR_OBJECT_DOES_NOT_EXIST
Object does not exist
Ваша проблема, по-видимому, связана с тем, что bar
"указывает" за пределы TimeSeries
-reverse-stepping-index значений Close[]
.
0 <= aBarPtrIDX < Bars
Следующая цель? Close[aBarPtrIDX]
заблуждение
После некоторого времени, проведенного в домене MQL4
, можно узнать несколько противоречивых фактов. Один из потенциальных сюрпризов заключается в том, что текущий бар, «горячий нуль» [0]
, содержит Close[0] == Bid
в течение всего срока его службы.
После того, как бегущая полоса завершается aNewBarEVENT
(сигнализируется Volume[0] == 1
(или Volume[0] < aPreviousVolume_0
- более безопасный режим для случая, MQL4
-слабо связанный цикл событий пропустил несколько quote
-поступлений во время своего занятого эпизода)), Close[1]
представляет последнюю посещенную цену в течение соответствующего периода Bar
, а Close[0]
продолжает просматривать постоянно меняющуюся цену Bid
.
person
user3666197
schedule
24.08.2015