https://www.mql5.com/en/forum/133792
The biggest problem trying to handle ordersend errors is No Result. You don't know wither the trade opened or not. My approach is to just return after logging for all errors. On the next tick, the orderSelect loop will tell me what orders are open and I can retry failed ones. Also by then transient errors (server is busy) should be gone. I assume that as soon as I issue the orderSend call, my PC crashes/reboots. On the next tick, the EA must be able to recover.
I would strongly suggest you look at the code WHRoeder posted on this page https://www.mql5.com/en/forum/133792 . . . read it, follow it, understand it . . . it will help you.
https://www.mql5.com/en/forum/133792
The biggest problem trying to handle ordersend errors is No Result. You don't know wither the trade opened or not. My approach is to just return after logging for all errors. On the next tick, the orderSelect loop will tell me what orders are open and I can retry failed ones. Also by then transient errors (server is busy) should be gone. I assume that as soon as I issue the orderSend call, my PC crashes/reboots. On the next tick, the EA must be able to recover.
Thanks so much for this, talk about a short-cut to the finish! I'm taking the advice, reading etc... and I may have one or two further questions on the best way to integrate my EA, for use with my Australian broker.(hope you don't mind?) For now, thanks again to all, especially WHRoeder... Magic.
Thanks so much for this, talk about a short-cut to the finish! I'm taking the advice, reading etc... and I may have one or two further questions on the best way to integrate my EA, for use with my Australian broker.(hope you don't mind?) For now, thanks again to all, especially WHRoeder... Magic.
Don't be so quick to follow those examples. Those are just examples of over-kill:
- too much unconventional/fanciful/weird formatting/indenting which may be convenient for the original author, but would not pass as acceptable coding examples in the real, commercial world, where someone else actually has to maintain your code. Artistic formatting may be the author's forte, but structured programming it is not.
- code pieces are plentiful from the author, but I have not yet seen a convincing equity curve. Artistic code formatters doesn't necessarily write profitable EA;'s.
- just because someone "strongly suggest" something doesn't make it gospel.
I am providing another point of view. The rest is up to you.
convincing equity curve. Artistic code formatters doesn't necessarily write profitable EA;'s.
Good error handling have nothing to do with a profitable EA. WHR's code does not have a trading logic included, so it might or might not be profitable, but thats not the point.
I think it is always harder to maintain/read someone else's code than his own but the OP asked for an example of error handling and this is what he get's.
additionally i can suggest to look at the OrderReliable library. Often discussed but i think a good example of error handling
Good error handling have nothing to do with a profitable EA. WHR's code does not have a trading logic included, so it might or might not be profitable, but thats not the point.
I think it is always harder to maintain/read someone else's code than his own but the OP asked for an example of error handling and this is what he get's.
additionally i can suggest to look at the OrderReliable library. Often discussed but i think a good example of error handling
"Good error handling have nothing to do with a profitable EA". That's not my point of argument.
This is what I said:
" Artistic code formatters doesn't necessarily write profitable EA;'s."
zzuegg:
additionally i can suggest to look at the OrderReliable library. Often discussed but i think a good example of error handling
No, is not a good example. It may be appropriate for some. That doesn't make it a "good example" for the rest.
The problem is it gets too fanciful, and tries to be too many things
to all sorts of possible error possibilities. In the coding world, the
more complex your code is, the more complex the problems you are going
to encounter.
If you are going to write an EA, you better understand what is
appropriate for your EA or not, rather than paste a whole bunch of code from some place which you don't understand, and then do a post-mortem as to why it wiped out your account balance.
"Good error handling have nothing to do with a profitable EA". That's not my point of argument.
This is what I said:
" Artistic code formatters doesn't necessarily write profitable EA;'s."
So you are saying you didnt intend that to be taken in context with this thread, ie regarding error handling code then what is your point ? I doubt you will ever "see" a profitable equity curve from many of the contributers of this forum for the simple reason, when they come up with a profitable strategy/ EA most are smart enough to keep it to themselves.
In the coding world, the more complex your code is, the more complex the problems you are going to encounter.
Hm, i cannot second that. The complexity of your code depends on the complexity of your problem,
In this case, you need to handle ~20 different error codes when sending orders, some of the retryable, some of them not. Some even require a waiting time and then check your open orders. I see no way to solve that problem with 10 lines of code. OrderReliable trys to handle all of them, of course you can implement a solid errorhandling for your EA with less complex code, (even OrderReliable fails sometimes and brings new problems) but my point is that you need to start somewhere, and in this case the codebase with 99% if(OrdersTotal()!=0) error handling is not a good starting point.
What would you consider a good lecture/piece of code for a programmer interested in mql4 error handling?
Hm, i cannot second that. The complexity of your code depends on the complexity of your problem,
What would you consider a good lecture/piece of code for a programmer interested in mql4 error handling?
OrdersReliable is overkill to me. But it may not be to you. My point is, was, do you understand what is appropriate for you/your strategy?
If so, that's the best course of action. If you don't, I have nothing else to say.
![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Hi to the Forum, and thanks for all replies to my question,
So, I have finished my Ea, but all that remains is the error handling. I'm not sure which errors to expect from the client terminal or trade server, or the best ways in which to handle these possible errors. Are there any experienced EA users that could spare a robust and reliable Error handling block to suit the following type of EA?
My simple EA only places market orders, no pending orders, and handles all exits (no fixed PT's or SL's attached to Buy or Sell orders).
I would like to feel comfortable that my EA can overcome simple errors returned from the client terminal or trade server, print to log, and perhaps prevent positions being opened if a critical error arises?
Obviously, I could use the sample Error handling block in the book, but I really wanted some insight into which errors to expect from trading the EA live. Does anyone have some good knowledge to share.
Any feedback and code samples are greatly appreciated.
Regards, Chris.