what is your design/strategy for 1 or more order close failures (retries exhausted) on 100% unattended multisym EA ?
I think error handling strategies should fit the specific expert and there is no one universal error handling strategy that is "the best" for all cases (although one might be used for convenience).
- When closing orders, the loop retries until ALL orders are closed (there is NO max retries). Of course there might be Sleep()'s for certain type of errors, but it would still close all orders once the closing criterion is met.
- When opening orders, if an attempt fails it reties for up to X retries and then the criterion for opening the order is re-evaluated, since the conditions for opening the order might or might not exist anymore.
(This is an example of an expert that uses market orders only... This expert can also be realized with pending orders and SL/TP, but then it wouldn't be an example here...).
I also do extensive usage of 'dynamic slippage' (used for non-ECN type brokers who use slippage control). For example, if an expert requires an order to be opened/closed within +/- X points of a certain price, then slippage is re-calculated on each retry (if there are errors) and adjusted so as the order will only open/close within those +/- X points. Another example - slippage is widened if there are too many re-quotes in a short time or if the expert identifies abnormal market conditions (spread widens, large and fast price movement, etc.). Of course, this does not work with certain 'ECN style' brokers that ignore slippage.
Thank you for detailed reply Gordon. I'm going to take the black 'n white option rea: closure of ALL via until all done... but maybe this is not total answer. ref:(*)
What are your views on:
concerning [amongst other candidates] ERR_TRADE_TIMEOUT
Is possible that the until could be long but your EAs #1 priority would be to see 100% closure, and until this priority achieved, normal operations would be abandoned. yes?
Further to 128, but less dramatic is one of let's say one out of n orders refuses to close and that the other orders are under a trail stop management scheme.
Would you interleave closure attempts with 'other' order management duties?
Assumes that one uses [at least] a protective S/L derived via MM and that should the worst occur, then is seen as a part of the loss statistics and nothing to worry about.
(*)
Above may be considered to obscure to worth it - but hit me that perhaps a few out of the many opened trades could be resisting closure and as such, until concept is of no use since others need ongoing management.
The last para is beyond me, but will be retained for future study... leading to enlightenment ;)
Thank you for detailed reply Gordon. I'm going to take the black 'n white option rea: closure of ALL via until all done... but maybe this is not total answer. ref:(*)
What are your views on:
concerning [amongst other candidates] ERR_TRADE_TIMEOUT
Is possible that the until could be long but your EAs #1 priority would be to see 100% closure, and until this priority achieved, normal operations would be abandoned. yes?
The dreaded error 128! I consider it to be the worst error u can have, since it can potentially suck up minutes of your expert's time. Additionally, it has the side-affect that if the open/close request was accepted, that information is NOT necessarily updated in the Terminal immediately after the request. So let's say u try to open an order and get error 128 a minute later, it does not mean that the order did not open! It might or might not have opened, and the worse is that if u check OrdersTotal() or the trade pool immediately after getting the reply, u might not see that order yet... The same goes for getting error 128 when attempting to close/closeby/modify an order.
Unfortunately, the only way to know if the order was actually closed/opened is to wait a few seconds and let the Terminal's order pool update. So in cases where I attempt open and get error 128, I wait a few seconds and verify that the order was indeed not opened before attempting again. In my previous example of closing all orders, I just continue with the next order and retry the whole loop again at the end (I put the for loop in an outer while loop).
Anyway, I used to have error 128 in the past quite often when I was trading from home, but ever since I moved to a dedicated server I very rarely get this error, so this error is definitely associated with network problems (as slawa wrote), so the best way to deal with this error is to avoid network problems in the first place.
Further to 128, but less dramatic is one of let's say one out of n orders refuses to close and that the other orders are under a trail stop management scheme.
Would you interleave closure attempts with 'other' order management duties?
Assumes that one uses [at least] a protective S/L derived via MM and that should the worst occur, then is seen as a part of the loss statistics and nothing to worry about.
(*)
Above may be considered to obscure to worth it - but hit me that perhaps a few out of the many opened trades could be resisting closure and as such, until concept is of no use since others need ongoing management.
The last para is beyond me, but will be retained for future study...
leading to enlightenment ;)
I don't think there is a general solution to this that is 'the best' in all cases. Again, it depends on the trading strategy of the specific expert. Obviously interleaving the attempts with other management duties would make the expert more complex to code, but might also affect the trading strategy itself.
In the past I played around with a complex 'interleaving' EA idea - basically, I had a 'to do' list in my expert. One block was responsible for checking open/close/modify criterion's and adding open/close/modify tasks to this list with priorities. A completely separate block was in charge of performing those tasks. Error handling capabilities were built into that block and interleaving decisions were done according to priorities... Well, it sounds good on paper, but eventually I gave up on this idea. It did not work very well and was too complicated to be worth it. To be honest I didn't give it enough time (well, I just didn't have enough time), so eventually I went back to the more traditional design.
[...] let's say one out of n orders refuses to close
The following brought to mind by a discussion on hedging which gordon and I have been participating in...
If you are closing multiple orders then - provided your broker supports it - I'd consider placing an opposing order for the size of your total position, and then repeatedly pairing things off. In other words, if you've got 5 buy orders for 0.2 lots, you place a sell order for 1 lot. And then repeatedly use OrderCloseBy().
This isn't pretty to do, because OrderCloseBy() keeps spawning new ticket numbers. However, as far as I'm concerned, it reduces the execution risk in MT4. If you're closing 5 orders, then there's the potential for the price to move quite strongly while those 5 separate requests are being handled one after the other. And there's 5 times the chance of encountering something like error #128. Of course, the price could move in your favour rather than against you, but personally I don't like the uncertainty. If you go down the pairing-and-offsetting route then your position is locked from the moment the closing order goes in (except for the effect of variations in the spread, but that's less significant than the risk from the price moving).
jjc wrote >>
If you are closing multiple orders then - provided your broker supports it - I'd consider placing an opposing order for the size of your total position, and then repeatedly pairing things off.
This is the single best idea I ever got from this forum. Never thought of doing it this way... Have been focusing too much on the errors themselves and not looking at the big picture. Thanks jjc.
... Of course, the price could move in your favour rather than against you, but personally I don't like the uncertainty.
I don't like the uncertainty either, but I have had occasions of making about 5x more than the target profit, simply because it took a relatively long time to close multiple orders during a price jump. I know that there is the potential for the opposite to happen (closing at a much higher loss), but that never happened to me, so it's hard to decide.
Since an EA must assume it could be restarted at any time (power failure) if must be coded to recover. So if a action fails, the EA should recover on the next tick.
If an order is sent, the EA should never try to open another until sufficient time (1 minute) as passed. Again the EA should recover by the next tick.
Most of the errors I see are modify/closing too close to market
/* A TP or SL can be not closer to the order price (open, limit, or * stop) or closing price (filled order) than this amount. A pend- * ing order price can be no closer to the current price than this * amount. On IBFX it's equal to 30 (3.0 pips.) */ minGap.stops = MarketInfo( Symbol(), MODE_STOPLEVEL )*Point; /* If the current price is closer than this to the TP, SL, (or pend- * ing price,) then the existing order can not be modified, closed, * or deleted. On IBFX it's equal to zero (in tester,) but I still * can't change it if it's closer than minGap.stops either. */ double minGap.change = MathMax(minGap.stops, MarketInfo( Symbol(), MODE_FREEZELEVEL )*Point); if ((now.close - stop.cur)*DIR< minGap.change) { // Can't change. continue; // now.close=Bid(buy)/Ask(sell) DIR=+1(buy)/-1(sell) }
If an order is sent, the EA should never try to open another until sufficient time (1 minute) as passed.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
I am cannot come to a conclusive strategy regards error handling - especially OrderClose(). For sure, an order with a S/L will eventually close, but what about early closure via EA decision ?
Not attempting to ruffle your feathers ;/ but most code seen is hard pressed to have any error checking, especially for calls to builtins.
Of course, some have error retry loop for handling the five trade function builtins.
But, Retry loops always end... eventually.
What does your design do when retries fail ?
What strategy do you use at such a time ?
eg,
maybe you go into hard loop [with suitable sleeps] and continue to deal with the offending order
or perhaps decide to start over again with closing cycle next data tick (yet, what about when tick separation is large?)
or
Perhaps you decided that your retry loop will always succeed ?
if so
What numbers used ? ie, retry count; sleep sizes; ...
For the record, with about 12yrs MT work, I have yet to experience such failure - pure luck I'd guess ;/
However I have come to think that 'just' having the usual error recovery from all manner of builtin error returns and most specifically trade function error handling retry loops etc,
is far from being a roboust EA design.
Getting aok OrderClose() must rank high on the list of must do's, yes?
After all, achieving profitable unattended 24/7 EA workings is most likely name of the game...
Thanking you in advance...