El problema de la transferencia de MT4 a MT5. O, más precisamente, la incapacidad de ejecutar algunos algoritmos en MT5 sin'err. - página 9

Nuevo comentario
 
Vict:

Sí, el código con excepciones es mucho más sencillo y limpio, la comprobación constante de errores lo convierte en un desastre. Pero hay muchos problemas en µl sin excepciones. Los promotores no tiraron de las cruces.

En mi opinión, no hay ninguna diferencia.

Con los códigos de retorno - necesitas escribir una macro como RETURN_IF_BAD_RESULT() y pegarla en todas las funciones que devuelven resultados.

Salvo excepciones, hay que escribir secciones de TRY-CACTH. Además tienes que recordar qué funciones lanzan excepción y cuáles no, añade comentarios // excepción a tu código.

Algo es pan comido, algo es...

 
Vict:

Sí, el código con excepciones es mucho más sencillo y limpio, la comprobación constante de errores lo convierte en un lío enmarañado. Pero hay muchos problemas en µl sin excepciones. Los promotores no pudieron tirar de las cruces.

No, ni siquiera estoy hablando de excepciones... alternativamente, podría haber un "malvado zapatero"... que convertirá todos los viajes fuera de la matriz en excepciones ))))

imho, sólo necesita una manera de romper todos los de retorno con la salida en OS ... que sea un poco de Exit(), tienes la idea correcta, no quiero multiplicar interminables carretes de código - no tiene sentido para envolver siempre todas las llamadas de función en

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

En mi opinión, no hay ninguna diferencia.

Con los códigos de retorno - necesitas escribir una macro como RETURN_IF_BAD_RESULT() y pegarla en todas las funciones que devuelven resultados.

Salvo excepciones, hay que escribir secciones de TRY-CACTH. Además - recuerda qué funciones lanzan una excepción y cuáles no, añade comentarios // excepción a tu código.

Algo es un lío, algo es un lío...

Con las excepciones no necesito recordar nada, muchas veces incluso TRY-CACTH no es necesario (simplemente terminará el crash del programa), es una situación EXCLUSIVA y normalmente no ocurre, no las conviertas en bloques if-else. Por ejemplo - escribí un vector (patético), en lugar de lanzar una excepción en las asignaciones fallidas tuve que joder al operador! y tirarlo en cada inserción (aunque lo estoy olvidando), dudoso beneficio.

 
Igor Makanu:

En mi opinión, sólo hay que ser capaz de romper todo con el sistema operativo...

Sí, eso también está bien, es extraño que no esté ahí...

 
Vict:

Sí, nada también, extraño que no esté presente ...

Simplemente no me parece conveniente convertir programas cortos con código legible en una especie de monstruo, aquí hay una plantilla típica para MQL4 - comprobar la "nueva barra", comprobar los indicadores - trabajar o no trabajar con órdenes:

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);
        }
     }
  }
//+------------------------------------------------------------------+

en este ejemplo, los indicadores "tiran cada tick" ya que trabajan en diferentes TFs... realmente no importa.

Utilizo los datos OHLC enind1(),ind2(),ind3() y enNewBar()

si obtengo un error de acceso a la serie de tiempo en una llamada a la función, ¿qué sentido tiene seguir ejecutando este código? - Necesito salir al SO y esperar un nuevo tick, es decir, en cualquierind1(),ind2(),ind3() y enNewBar() compruebo GetLastError() y al recibir un error inmediatamente Exit() en el SO con la escritura en el registro de EA

 
Vict:

Con las excepciones no tengo que recordar nada, a menudo incluso TRY-CACTH no es necesario (el programa simplemente terminará en una emergencia), es una situación EXCLUSIVA y no ocurre normalmente, no las conviertas en bloques if-else. Por ejemplo - escribí un vector (patético), en lugar de lanzar una excepción en las asignaciones fallidas tuve que joder al operador! y tirarlo en cada inserción (aunque lo estoy olvidando), dudoso beneficio.

Bueno, vamos, amigo...

Este mismo "a menudo" significa que algún bloque es necesario y otro no, y hay que recordarlo. La situación es la misma que con los códigos de retorno: si se solicita algún recurso y se produce una excepción (se devuelve un error), los recursos deben ser rechazados. Es decir, en cualquier caso, debes recordar qué función lanza una excepción y cuál no.

Ah, y sobre la "situación excepcional"... Bueno, cómo puedo decir... La ausencia de comillas parece un motivo razonable para lanzar una excepción, pero ¿es una "situación excepcional"?

 
Igor Makanu:

Simplemente no me siento cómodo convirtiendo programas cortos con código legible en una especie de monstruo, aquí hay una plantilla típica para MQL4 - comprobar la "nueva barra", comprobar los indicadores - trabajar o no trabajar con órdenes:

en este ejemplo, los indicadores "tiran cada tick" ya que trabajan en diferentes TFs... realmente no importa.

Utilizo los datos OHLC enind1(),ind2(),ind3() y enNewBar()

si obtengo un error de acceso a la serie de tiempo en una llamada a la función, ¿qué sentido tiene seguir ejecutando este código? - Necesito salir al SO y esperar un nuevo tick, es decir, en cualquier ind1(),ind2(),ind3() y enNewBar() compruebo GetLastError() y después de obtener un error inmediatamente Exit() en el SO con registro en el log de EA

¿Cuál es el problema de llamar a return(iErrrCode)?

 
Georgiy Merts:

¿Y cuál es el problema de llamar a return(iErrrCode)?

Hm, trataré de mostrarlo en el código, reescribí el código con salida si los datos OHLC fueron procesados incorrectamente, se verá así:

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);
        }
     }
  }

ahora obtengo los valores de la función por referencia y salgo si la función fue procesada incorrectamente (en el contexto de la discusión - la terminal no preparó losdatos históricos por TF)

 
Georgiy Merts:

Bueno, vamos, amigo...

Este mismo "a menudo" significa que algún bloque es necesario y otro no, y hay que recordarlo. La situación es la misma que con los códigos de retorno: si se solicita algún recurso y se produce una excepción (se devuelve un error), los recursos deben ser rechazados. Es decir, en cualquier caso, debes recordar qué función lanza una excepción y cuál no.

Ah, y sobre la "situación excepcional"... Bueno, cómo puedo decir... La ausencia de comillas es algo razonable para lanzar una excepción, pero ¿es una "situación excepcional"?

De alguna manera has utilizado las excepciones a tu manera, erróneamente, al parecer. Generalmente, no debería preocuparse por si esta función lanza una excepción o no. Tener TRY-CATCH es opcional. Y para evitar problemas de recursos, consiga 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, al girar la pila se limpiará todo.

Y sobre la "situación excepcional"... Bueno, cómo decirlo... La falta de citas parece una excusa razonable para lanzar una excepción, pero ¿es una "situación excepcional"?
La exclusividad depende del autor del código, pero las excepciones no deben ser análogas a los if-else, por supuesto.
 

Curiosamente, no se me había ocurrido antes:

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

Se deshace de una masa de comprobación de errores, como la asignación de memoria.

123456789101112
Nuevo comentario