O problema da transferência do MT4 para o MT5. Ou, mais precisamente, a incapacidade de executar alguns algoritmos no MT5 sem errar. - página 9

Novo comentário
 
Vict:

Sim, o código com exceções é muito mais simples e limpo, a verificação constante de erros o transforma em uma bagunça. Mas há muitos problemas em µl sem exceções. Os desenvolvedores não puxaram as cruzes.

Na minha opinião, não há diferença.

Com códigos de retorno - você precisa escrever uma macro como RETURN_IF_BAD_RESULT() e colá-la em todas as funções que retornam resultados.

Com exceções - você precisa escrever seções TRY-CACTH. Além disso, você tem que lembrar quais funções lançam exceção e quais não lançam, adicionar comentários // exceção ao seu código.

Alguma coisa é canja, alguma coisa é...

 
Vict:

Sim, o código com exceções é muito mais simples e limpo, a verificação constante dos erros o transforma em uma bagunça confusa. Mas há muitos problemas em µl sem exceções. Os desenvolvedores não conseguiam puxar as cruzes.

Não, nem sequer estou falando de exceções... alternativamente, pode haver um "sapateiro malvado"... que transformarão todas as viagens fora da matriz em exceções ))))

imho, você só precisa de uma maneira de quebrar todo o retorno com a saída para o SO... que seja alguma saída(), você acertou a idéia, eu não quero multiplicar infinitos spools de código - não faz sentido enrolar sempre todas as chamadas de função em

void OnStart()
{
if(!MyFuncReadOHLC_1()) return;
if(!MyFuncReadOHLC_2()) return;
....
}
 
Georgiy Merts:

Na minha opinião, não há diferença.

Com códigos de retorno - você precisa escrever uma macro como RETURN_IF_BAD_RESULT() e colá-la em todas as funções que retornam resultados.

Com exceções - você precisa escrever seções TRY-CACTH. Além disso - lembre-se quais funções lançam uma exceção e quais não, acrescente comentários // exceção ao seu código.

Algo está uma confusão, algo está uma confusão...

Com exceções não preciso me lembrar de nada, muitas vezes nem mesmo o TRY-CACTH é necessário (apenas terminará o crash do programa), é uma situação EXCLUSIVA e normalmente não acontece, não os transforme em blocos if-else. Por exemplo - escrevi um vetor (patético), em vez de lançar exceções em alocações mal sucedidas tive que parafusar o operador! e puxá-lo a cada inserção (embora eu esteja esquecendo), benefício duvidoso.

 
Igor Makanu:

imho, você só precisa ser capaz de quebrar tudo com o sistema operacional...

Sim, tudo bem também, é estranho que não esteja lá ...

 
Vict:

Sim, nada também, estranho que não esteja presente ...

Apenas não acho conveniente transformar programas curtos com código legível em algum tipo de monstro, aqui está um modelo típico para MQL4 - verifique a "nova barra", verifique os indicadores - trabalhe ou não trabalhe com pedidos:

void OnTick()
  {
   int takeprofit,stoploss; 
   double lot;
   ENUM_CMD CMD1,CMD2,CMD3;
   CMD1 = ind1();
   CMD2 = ind2();
   CMD3 = ind3();
   if(NewBar())
     {
      DeleteOrdersLimits(Magic);
      if(CMD1==CMD_BUY && CMD2==CMD_BUY && CMD3==CMD_BUY)
        {
         CalcTakeProfitStopLoss(takeprofit,stoploss);
         lot=CalcLot(stoploss);
         if(ReversSignal)SELL_STOP_PR(Low[1],lot,Magic,stoploss,takeprofit); else BUY_STOP_PR(High[1],lot,Magic,stoploss,takeprofit);
        }
      if(CMD1==CMD_SELL && CMD2==CMD_SELL && CMD3==CMD_SELL)
        {
         CalcTakeProfitStopLoss(takeprofit,stoploss);
         lot=CalcLot(stoploss);
         if(ReversSignal)BUY_STOP_PR(High[1],lot,Magic,stoploss,takeprofit);else SELL_STOP_PR(Low[1],lot,Magic,stoploss,takeprofit);
        }
     }
  }
//+------------------------------------------------------------------+

neste exemplo, os indicadores "puxam cada tique" enquanto trabalham em TFs diferentes. isso não importa realmente.

Eu uso dados OHLC emind1(),ind2(),ind3() e emNewBar()

se eu receber um erro de acesso de série temporal em uma chamada de função, qual é o objetivo de continuar a executar este código? - Preciso sair para OS e esperar por um novo tick, ou seja, em qualquerind1(),ind2(),ind3() e emNewBar() Eu verifico GetLastError() e ao receber um erro imediatamente Exit() em OS com escrita no log EA

 
Vict:

Com exceções não tenho que me lembrar de nada, muitas vezes nem mesmo TRY-CACTH é necessário (o programa simplesmente terminará em uma emergência), é uma situação EXCLUSIVA e não acontece normalmente, não os transforme em blocos if-else. Por exemplo - escrevi um vetor (patético), em vez de lançar exceções em alocações mal sucedidas tive que parafusar o operador! e puxá-lo a cada inserção (embora eu esteja esquecendo), benefício duvidoso.

Bem, vamos lá, companheiro...

Você diz: "você não precisa se lembrar de nada", e então você continua: Muitas vezes nem mesmo TRY-CATCH é necessário. Este mesmo "frequentemente" significa que em algum lugar é necessário bloquear e em algum lugar não é necessário, e você precisa se lembrar disso. A situação é a mesma que com os códigos de retorno - se você solicitar algum recurso e ocorrer uma exceção (erro é devolvido), os recursos devem ser rejeitados. Ou seja, em qualquer caso, é preciso lembrar qual função abre uma exceção e qual não abre.

Ah, e sobre a "situação excepcional"... Bem, como posso dizer... A ausência de citações parece ser uma razão razoável para lançar uma exceção, mas será que se trata de uma "situação excepcional"?

 
Igor Makanu:

Apenas não acho conveniente transformar programas curtos com código legível em algum tipo de monstro, aqui está um modelo típico para MQL4 - verifique a "nova barra", verifique os indicadores - trabalhe ou não trabalhe com pedidos:

neste exemplo, os indicadores "puxam cada tique" enquanto trabalham em TFs diferentes. isso não importa realmente.

Eu uso dados OHLC emind1(),ind2(),ind3() e emNewBar()

se eu receber um erro de acesso de série temporal em uma chamada de função, qual é o objetivo de continuar a executar este código? - Preciso sair para OS e esperar por um novo tick, ou seja, em qualquer ind1(),ind2(),ind3() e emNewBar() eu verifico GetLastError() e depois de receber um erro imediatamente Exit() em OS com gravação no log EA

Qual é o problema em chamar retorno (iErrrCode)?

 
Georgiy Merts:

E qual é o problema para chamar retorno(iErrrCode) ?

Hm, vou tentar mostrá-lo no código, reescrevi o código com saída se os dados OHLC foram processados incorretamente, vai parecer assim:

void OnTick()
  {
   int takeprofit,stoploss; 
   double lot;
   bool nb;
   ENUM_CMD CMD1,CMD2,CMD3;
   if(!ind1( CMD1 )) return;
   if(!ind2( CMD2 )) return;
   if(!ind3( CMD3 )) return;
   if(!NewBar( nb )) return;
   
   if( nb )
     {
      DeleteOrdersLimits(Magic);
      if(CMD1==CMD_BUY && CMD2==CMD_BUY && CMD3==CMD_BUY)
        {
         CalcTakeProfitStopLoss(takeprofit,stoploss);
         lot=CalcLot(stoploss);
         if(ReversSignal)SELL_STOP_PR(Low[1],lot,Magic,stoploss,takeprofit); else BUY_STOP_PR(High[1],lot,Magic,stoploss,takeprofit);
        }
      if(CMD1==CMD_SELL && CMD2==CMD_SELL && CMD3==CMD_SELL)
        {
         CalcTakeProfitStopLoss(takeprofit,stoploss);
         lot=CalcLot(stoploss);
         if(ReversSignal)BUY_STOP_PR(High[1],lot,Magic,stoploss,takeprofit);else SELL_STOP_PR(Low[1],lot,Magic,stoploss,takeprofit);
        }
     }
  }

agora recebo valores de função por referência e saio se a função foi processada incorretamente (no contexto de discussão - o terminal não preparoudados históricos pela TF)

 
Georgiy Merts:

Bem, vamos lá, companheiro...

Você diz: "você não precisa se lembrar de nada", e então você continua: Muitas vezes nem mesmo TRY-CATCH é necessário. Este mesmo "frequentemente" significa que em algum lugar é necessário bloquear e em algum lugar não é necessário, e você precisa se lembrar disso. A situação é a mesma que com os códigos de retorno - se você solicitar algum recurso e ocorrer uma exceção (erro é devolvido), os recursos devem ser rejeitados. Ou seja, em qualquer caso, é preciso lembrar qual função abre uma exceção e qual não abre.

Ah, e sobre a "situação excepcional"... Bem, como posso dizer... A ausência de citações é uma coisa razoável para lançar uma exceção, mas será uma "situação excepcional"?

Você de alguma forma usou exceções à sua própria maneira, erroneamente, aparentemente. Em geral, você não deve se preocupar se esta função abre ou não uma exceção. Ter TRY-CATCH é opcional. E para evitar problemas de recursos, obtenha a RAIIhttps://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BB%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5_%D1%80%D0%B5%D1%81%D1%83%D1%80%D1%81%D0%B0_%D0%B5%D1%81%D1%82%D1%8C_%D0%B8%D0%BD%D0%B8%D1%86%D0%B8%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F, girando a pilha limpará tudo.

E sobre "situação excepcional"... Bem, como posso dizer... A falta de citações parece ser uma desculpa razoável para lançar uma exceção, mas será uma "situação excepcional"?
A exclusividade depende do autor do código, mas as exceções não devem ser análogas ao if-else, é claro.
 

Curiosamente, eu não tinha pensado nisso antes:

// Немедленное завершение, деструкторы не вызываются
void abort() {Alert(1/(uint)MathAbs(0));}

Ele se livra de alguma massa de verificação de erros, como alocação de memória.

123456789101112
Novo comentário
Razão: