Il problema del trasferimento da MT4 a MT5. O, più precisamente, l'impossibilità di eseguire alcuni algoritmi in MT5 senza 'err. - pagina 9

Nuovo commento
 
Vict:

Sì, il codice con le eccezioni è molto più semplice e pulito, il controllo costante degli errori lo trasforma in un casino. Ma ci sono molti problemi in µl senza eccezioni. Gli sviluppatori non hanno tirato le croci.

Secondo me, non c'è differenza.

Con i codici di ritorno - dovete scrivere una macro come RETURN_IF_BAD_RESULT() e inserirla in tutte le funzioni che restituiscono risultati.

Con eccezioni - è necessario scrivere sezioni TRY-CACTH. Inoltre dovete ricordare quali funzioni lanciano eccezioni e quali no, aggiungete commenti // eccezione al vostro codice.

Qualcosa è un gioco da ragazzi, qualcosa è...

 
Vict:

Sì, il codice con le eccezioni è molto più semplice e pulito, il controllo costante degli errori lo trasforma in un groviglio. Ma ci sono molti problemi in µl senza eccezioni. Gli sviluppatori non potevano tirare le croci.

No, non sto nemmeno parlando di eccezioni... in alternativa, potrebbe esserci un "ciabattino malvagio"... che trasformerà tutti i viaggi al di fuori dell'array in eccezioni ))))

imho, hai solo bisogno di un modo per rompere tutti i ritorni con exit in OS... lascia che sia qualche Exit(), hai avuto l'idea giusta, non voglio moltiplicare gli spool di codice senza fine - non ha senso avvolgere sempre tutte le chiamate di funzione in

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

Secondo me, non c'è differenza.

Con i codici di ritorno - dovete scrivere una macro come RETURN_IF_BAD_RESULT() e inserirla in tutte le funzioni che restituiscono risultati.

Con eccezioni - è necessario scrivere sezioni TRY-CACTH. Inoltre - ricordate quali funzioni lanciano un'eccezione e quali no, aggiungete commenti // eccezione al vostro codice.

Qualcosa è un casino, qualcosa è un casino...

Con le eccezioni non ho bisogno di ricordare nulla, spesso anche TRY-CACTH non è necessario (semplicemente terminerà il crash del programma), è una situazione ESCLUSIVA e normalmente non accade, non trasformarli in blocchi if-else. Per esempio - ho scritto un vector-like (patetico-like), invece di lanciare un'eccezione sulle allocazioni non riuscite ho dovuto fregare operator! e strattonarlo ad ogni inserimento (anche se me ne sto dimenticando), beneficio dubbio.

 
Igor Makanu:

imho, devi solo essere in grado di rompere tutto con il sistema operativo...

Sì, anche questo va bene, strano che non ci sia...

 
Vict:

Sì, anche niente, strano che non sia presente...

Solo che non mi sento a mio agio a trasformare programmi brevi con codice leggibile in una specie di mostro, ecco un tipico modello per MQL4 - controllare la "nuova barra", controllare gli indicatori - lavorare o non lavorare con gli ordini:

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

in questo esempio, gli indicatori "tirano ogni tick" perché lavorano su diversi TF... non ha molta importanza.

Uso i dati OHLC inind1(),ind2(),ind3() e inNewBar()

se ottengo un errore di accesso alle serie temporali in una chiamata di funzione, che senso ha continuare ad eseguire questo codice? - Ho bisogno di uscire in OS e aspettare un nuovo tick, cioè in qualsiasiind1(),ind2(),ind3() e inNewBar() controllo GetLastError() e quando ricevo un errore esco immediatamente da OS con la scrittura nel log EA

 
Vict:

Con le eccezioni non devo ricordare nulla, spesso anche il TRY-CACTH non è necessario (il programma terminerà semplicemente in caso di emergenza), è una situazione ESCLUSIVA e non accade normalmente, non trasformarli in blocchi if-else. Per esempio - ho scritto un vector-like (patetico-like), invece di lanciare un'eccezione sulle allocazioni non riuscite ho dovuto fregare operator! e strattonarlo ad ogni inserimento (anche se me ne sto dimenticando), beneficio dubbio.

Beh, andiamo, amico...

Tu dici, "non c'è bisogno di ricordare nulla", e poi continui: spesso anche TRY-CATCH non è necessario. Questo stesso "spesso" significa che da qualche parte il blocco è necessario e da qualche parte non è necessario, e bisogna ricordarlo. La situazione è la stessa dei codici di ritorno - se si richiede qualche risorsa e si verifica un'eccezione (viene restituito un errore), le risorse devono essere respinte. Cioè, in ogni caso, dovete ricordare quale funzione lancia un'eccezione e quale no.

Oh, e riguardo alla "situazione eccezionale"... Beh, come posso dire... L'assenza di citazioni sembra essere un motivo ragionevole per lanciare un'eccezione, ma è una "situazione eccezionale"?

 
Igor Makanu:

Solo che non mi sento a mio agio a trasformare programmi brevi con codice leggibile in una specie di mostro, ecco un tipico modello per MQL4 - controllare la "nuova barra", controllare gli indicatori - lavorare o non lavorare con gli ordini:

in questo esempio, gli indicatori "tirano ogni tick" perché lavorano su diversi TF... non ha molta importanza.

Uso i dati OHLC inind1(),ind2(),ind3() e inNewBar()

se ottengo un errore di accesso alle serie temporali in una chiamata di funzione, che senso ha continuare ad eseguire questo codice? - Ho bisogno di uscire in OS e aspettare un nuovo tick, cioè in qualsiasi ind1(),ind2(),ind3() e inNewBar() controllo GetLastError() e dopo aver ottenuto un errore immediatamente Exit() in OS con registrazione nel log EA

Qual è il problema nel chiamare return(iErrrCode) ?

 
Georgiy Merts:

E qual è il problema di chiamare return(iErrrCode)?

Hm, proverò a mostrarlo nel codice, ho riscritto il codice con l'uscita se i dati OHLC sono stati elaborati in modo errato, sarà come questo:

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

ora ottengo i valori della funzione per riferimento e esco se la funzione è stata elaborata in modo errato (nel contesto della discussione - il terminale non ha preparatoi dati storici per TF)

 
Georgiy Merts:

Beh, andiamo, amico...

Tu dici "non c'è bisogno di ricordare nulla", e poi continui: spesso anche TRY-CATCH non è necessario. Questo stesso "spesso" significa che da qualche parte il blocco è necessario e da qualche parte non è necessario, e bisogna ricordarlo. La situazione è la stessa dei codici di ritorno - se si richiede qualche risorsa e si verifica un'eccezione (viene restituito un errore), le risorse devono essere respinte. Cioè, in ogni caso, dovete ricordare quale funzione lancia un'eccezione e quale no.

Oh, e riguardo alla "situazione eccezionale"... Beh, come posso dire... L'assenza di citazioni è una cosa ragionevole per lanciare un'eccezione, ma è una "situazione eccezionale"?

Lei ha in qualche modo usato le eccezioni a modo suo, a torto, a quanto pare. In generale, non dovreste preoccuparvi del fatto che questa funzione lanci un'eccezione o meno. Avere TRY-CATCH è opzionale. E per evitare problemi di risorse, prendete 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, far girare lo stack pulirà tutto.

E riguardo alla "situazione eccezionale"... Beh, come posso dire... La mancanza di citazioni sembra essere una scusa ragionevole per lanciare un'eccezione, ma è una "situazione eccezionale"?
L'esclusività spetta all'autore del codice, ma le eccezioni non dovrebbero essere analoghe agli if-else, ovviamente.
 

Stranamente, non ci avevo pensato prima:

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

Si sbarazza di alcune masse di controllo degli errori, come l'allocazione della memoria.

123456789101112
Nuovo commento