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
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
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 é...
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
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.
imho, você só precisa ser capaz de quebrar tudo com o sistema operacional...
Sim, tudo bem também, é estranho que não esteja lá ...
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:
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
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"?
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)?
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:
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)
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.
Curiosamente, eu não tinha pensado nisso antes:
Ele se livra de alguma massa de verificação de erros, como alocação de memória.