Почему в MQL5 нет исключений? - страница 11
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Они у них уже сделаны. Подход такой - проверки вместо эксепшнов.
{
ResetLastError();
datetime dt = StringToTime("2017.01.35 10:52");
int err = GetLastError();
Print("err=", ErrorDescription(err), " dt=", dt);
dt = StringToTime("2016.01&08 10:52");
err = GetLastError();
Print("err=", ErrorDescription(err), " dt=", dt);
dt = StringToTime("2016.0108 10:52");
err = GetLastError();
Print("err=", ErrorDescription(err), " dt=", dt);
dt = StringToTime("2016.01.08 48:52:256");
err = GetLastError();
Print("err=", ErrorDescription(err), " dt=", dt);
Print("end");
}
Тут не нужно быть разработчиком железа, достаточно вместо вечернего пива заняться самообразованием. Гуглим "прерывания просессора" или "interrupt"и изучаем, все довольно просто.
Вот табличка прерывания для x86, стрелочками обозначил аппаратные прерывания, которые возникают при определенных событиях в процессоре. Если бы их не было, винда падала бы через каждые 10 секунд ))
Зайцев очень правильно сформулировал:
Понимаешь , я о той ситуации при которой достаточно добиться того, что бы программа не вылетала а продолжала работать.
Но почему-то обсуждаются ситуации с делением на ноль и Вы расширили их на все аварийные завершения процессора
Я смотрю на проблему шире, так как считаю, советник должен перехватывать все аварийные завершения своего функционирования. Нельзя допускать, чтобы программа предназначенная для работы в режиме 24/7 аварийно завершилась в тот момент когда пошел за пивом или спишь.
По мне перечень аварийных завершений работы советников гораздо больше, чем прерываний по процессору, более того количество их не определенно и зависит от используемых алгоритмов.
Я такой пример приводил выше, когда попытка построения модели оказывается неудачной и, если не использовать try, то в некоторых моделях программа завершится аварийно уже внутри модели.
Если принять, что перечень исключительных состояний не известен, то механизмом, представленным не только в С# и R, является механизм try/catch, который имеется и в других языках программирования. Именно этот механизм обеспечивает работу советника в режиме реального времени.
Если принять, что перечень исключительных состояний не известен, то все эти рекомендации "проверять знаменатель перед делением" выглядят наивными: пусть попробуют проверить входные данные для какой-либо модели, а самое главное зачем? Проверяешь результат на try/catch и все дела.
Это специфический прикладной язык, от которого зависит состояние баланса счета.
Что важнее?
предусмотреть всевозможные проверки перед тем как допустить к реальным деньгам или рисковать счетом? особенно чужим и немаленьким
Исключения являются угрозой безопасности торгового счета - не факт, совсем не факт.
Я уверен в том что исключения будут полезны для торговли, вопрос в другом, вопрос в том сколько разработчиков торговых роботов смогут действительно грамотно и адекватно использовать исключения в своих проектах. Мне кажется стоит подумать над реализацией, но, вначале все взвесить нужно и оценить, спешить не стоит.
Исключения являются угрозой безопасности торгового счета - не факт, совсем не факт.
Я уверен в том что исключения будут полезны для торговли, вопрос в другом, вопрос в том сколько разработчиков торговых роботов смогут действительно грамотно и адекватно использовать исключения в своих проектах. Мне кажется стоит подумать над реализацией, но, вначале все взвесить нужно и оценить, спешить не стоит.
Судя по положению дел с массовым изучением ООП, тут будет, над чем поработать ))
Забыл сказать, я голоснул за 2-й пункт, это ж не принудительно, кто то будет использовать а кто то нет, если будет такая фича в языке то не помешает. Но я лично никогда не стал бы использовать исключения в ПО для торговли.
А почему нет. Если реализация грамотная и все продумано в чем риск?
Другое дело, если не очень адекватные программисты будут это использовать для "бомбардировки" торговых серверов некорректными запросами или еще что-то в этом роде начнут делать.
На мой взгля вполне возможно такое реализовать, только предварительно проверки на стороне терминала и сервера усложнить, особо в самом терминале.
Господа, вы видели реакцию терминала на:
Все эти ошибки терминал эффективно перехватывает, правильно о них сообщает и обеспечивает непрерывную работоспособность терминала. Ну а проштрафившаяся программа конечно снимается с выполнения.
Почему? Потому что терминал и среда выполнения MQL5 построены на полном и жестком контроле всего MQL5(и даже DLL) кода. И тут мы слышим смешные обвинения, что мы что-то не продумали, что-то не знаем и плохо выполняем свою работу.
Есть два основных метода работы с ошибками: коды возврата и эксепшены. В MQL5 это коды возврата и система меняться не будет.
Не забывайте, что над над вашими проверками внутри вашего кода всегда стоит полный неотключаемый контроль со стороны среды выполнения.
Почему не делают в самолётах стоп-кран? Потому что бесполезно пить боржоми и всё такое... Т.е. не нужно пытаться спасти положение изнутри падающей программы.
На счет OnError(). Не пойму в чем конкретно проблема? Кто мешает самостоятельно реализовать нужный функционал в самом торговом роботе или в основном классе.
Я лично так делаю года с 2011 и все отлично работает. Причем параметры можно какие угодно прописать, особо если реализацию делать в пользовательских классах.
Вообще, честно говоря, не стоит ориентироваться на "примеры" (мягко говоря) из базы или на стандартные классы, лучше все прописывать самостоятельно.
Господа, вы видели реакцию терминала на:
Все эти ошибки терминал эффективно перехватывает, правильно о них сообщает и обеспечивает непрерывную работоспособность терминала. Ну а проштрафившаяся программа конечно снимается с выполнения.
Почему? Потому что терминал и среда выполнения MQL5 построены на полном и жестком контроле всего MQL5(и даже DLL) кода. И тут мы слышим смешные обвинения, что мы что-то не продумали, что-то не знаем и плохо выполняем свою работу.
Есть два основных метода работы с ошибками: коды возврата и эксепшены. В MQL5 это коды возврата и система меняться не будет.
Не забывайте, что над над вашими проверками внутри вашего кода всегда стоит полный неотключаемый контроль со стороны среды выполнения.
При делении на ноль советник отключается с сообщением в терминале. Да, терминал не падает. Что делать с открытыми ордерами?
{
int a = 20, b = 21, c = 80, d = 0;
d = c/(a - --b);
return(INIT_SUCCEEDED);
}
2017.01.31 12:38:26.495 TestException (EURUSD,M1) zero divide in 'TestException.mq5' (15,12)
На счет OnError(). Не пойму в чем конкретно проблема? Кто мешает самостоятельно реализовать нужный функционал в самом торговом роботе или в основном классе.
Я лично так делаю года с 2011 и все отлично работает. Причем параметры можно какие угодно прописать, особо если реализацию делать в пользовательских классах.
Вообще, честно говоря, не стоит ориентироваться на "примеры" (мягко говоря) из базы или на стандартные классы, лучше все прописывать самостоятельно.
...
Если принять, что перечень исключительных состояний не известен, то все эти рекомендации "проверять знаменатель перед делением" выглядят наивными: пусть попробуют проверить входные данные для какой-либо модели, а самое главное зачем? Проверяешь результат на try/catch и все дела.
Ага... просто всего эксперта оборачиваешь в try/catch авось заработает.