Будут ли добавлены в MQL исключительные ситуации?

 

Если тут сидят люди, осведомленные о ходе разработки MQL, подскажите, будет ли добавлена в MQL возможность работы с исключительными ситуациями?

 
Вадим Калашнков:

Если тут сидят люди, осведомленные о ходе разработки MQL, подскажите, будет ли добавлена в MQL возможность работы с исключительными ситуациями?

Вроде бы когда-то пришли к выводу, что коды возврата более разумны. Но, это было давно, и с тех пор разговоров на эту тему не было.

 
Georgiy Merts #:

Вроде бы когда-то пришли к выводу, что коды возврата более разумны. Но, это было давно, и с тех пор разговоров на эту тему не было.

я похоже вообще нуб, что за исключительные ситуации?

Жорж похоже понял, значит я точно нуб

 
Fast235 #:

что за исключительные ситуации?

Ну это обработка ошибок в языках ООП.

exception, try, raise...

Очень удобно работать с ошибками, чтобы не проверять коды возврата после каждой строки. Сильно упрощает код, уменьшает вероятность необработанных ошибок. Производительность системных функций и операций уменьшает, но если писать код с доскональными проверками на ошибки (как делаю я), всё переносится на пользователя - "его код медленный".

 
Edgar Akhmadeev #:

Ну это обработка ошибок в языках ООП.

exception, try, raise...

Очень удобно работать с ошибками, чтобы не проверять коды возврата после каждой строки. Сильно упрощает код, уменьшает вероятность необработанных ошибок. Производительность системных функций и операций уменьшает, но если писать код с доскональными проверками на ошибки (как делаю я), всё переносится на пользователя - "его код медленный".

Спасибо, попробую разобраться

 
Fast235 #:

я похоже вообще нуб, что за исключительные ситуации?

Жорж похоже понял, значит я точно нуб

Вот небольшой пример на C++. Где бы не произошла какая либо ошибка (на любом уровне), она прилетит в этот обработчик. Так же можно писать свои классы исключительных ситуаций, а далее, делать свой catch в зависимости от класса, который выбросил исключительную ситуацию. Инструмент крайне удобный.

class Trade
{
public:
  Trade() {}
 ~Trade() {}
 
 void make_position();
};

void Trade::make_position()
{
  .....
  
  if (!result)
    throw std::runtime_error("Failed to make position: " + error_to_string(ret_code));
}

class Expert
{
public:
  Expert() {}
 ~Expert() {}
 
  void process();
private:
  Trade _trade;
};

void Expert::process()
{
  .....
  _trade.make_position();
}

OnTick()
{
  Expert expert;

  try
  {
    expert.process();
  }
  catch (const std::exception& ex) 
  {
    std::cout << "Failed to process: << ex.what() << std::endl;
    // Do thomesing on error.
  }
}
Тут, в функции process мы не делаем никакой проверки успешности make_position, но функция прерывает выполнение там, где была исключительная ситуация, а отлавливаем мы ее аж на уровень выше, в OnTick.
 
Georgiy Merts #:

Вроде бы когда-то пришли к выводу, что коды возврата более разумны. Но, это было давно, и с тех пор разговоров на эту тему не было.

Коды возврата кодами возврата, но это другой механизм и используется немного для разных целей. 

 
Вадим Калашнков #:

Вот небольшой пример на C++.

классический антипаттерн, характерный для любителей пихать исключения куда ни попадя )

ошибка при открытии позиции это рядовая ситуация и исключением не является

 
Andrei Trukhanovich #:

классический антипаттерн, характерный для любителей пихать исключения куда ни попадя )

ошибка при открытии позиции это рядовая ситуация и исключением не является

Я прекрасно понимаю, что это анти паттерн и для чего нужны исключительные ситуации. На то они и исключительные, что бы их не пихать куда не попадя. Однако для 235 такой пример реализации более понятен нежели, передача неверного формата данных и прочее.

Более корректный пример:

double Math::divide(double a, double b)
{
  if (std::fabs(b) < std::numeric_limits<double>::epsilon)
    throw std::runtime_error("Zero division");

  return a / b;
}
 

Эти примеры не очень впечатлят тех, кто не знает удобства исключений. Если объяснить обобщённо и на псевдокоде, вот процедурная методика:

{
операция
проверка ошибок
обработка ошибок

операция
проверка ошибок
обработка ошибок

операция
проверка ошибок
обработка ошибок
}

Вот ООП методика:

try {
        операция
        операция
        операция
}

catch (НедостаточноПамяти) {
        обработка ошибки
}

catch (ДелениеНаНоль) {
        обработка ошибки
}

catch (ОшибкаСервера) {
        обработка ошибки
}
Знакомая ситуация, когда чуть не после каждой строки проверяем и обрабатываем?
 
Fast235 #:

я похоже вообще нуб, что за исключительные ситуации?

Жорж похоже понял, значит я точно нуб

Это альтернативный способ передать в место вызова уведомление об ошибке в вызываемой функции. 

Вопреки верованиям некоторых адептов, не обладает мистической силой. Для того, чтобы оно работало, в функциях надо генерировать эти сообщения об ошибках. 

При отсутствии сего артефакта, миссия выполняется обычными функциями, возвращающими true/false, в зависимости от успешности их работы, а результат работы функции (значение) "возвращаются" по ссылке. То есть отсутствие сего артефакта не является поводом для печали.

Причина обращения: