I have a "set up" on my EA to ping me an email when my Expert Advisor experiences an error and provides me the error code in accordance with the pre-determined 3-4 digit error code in the documentation on the MQL4 website.
/* technically speaking,
error codes with 5+ digits are also possible,
Using:
------ */
SetUserError( 1000000 ); /*
// this will set an error-state
// with a number 1065536 -- having a bit more than the said 3 ~ 4 digits
// composed as ( 1000000 + ERR_USER_ERROR_FIRST )
*/
This is to enable me to diagnose the problem.
Just wanting to clarify if I need to refresh the error code ( from a previous error ) I'm getting in my email, or does it do this automatically, when a new error is presented in the Journal of my MT4 Platform?
There is a helpful function ResetLastError() that explicitly sets _LastError to zero. Next, there is also a side effect of each call to a GetLastError() function, as it also sets zero to the _LastError variable.
Either way, it is a common practice to embed ( surround ) a section, where some error-states need to get handled accordingly, right by a:
// -------------------------------------------- // START_________________________
GetLastError(); // implicit pre-reset _LastError
ResetLastError(); // explicit pre-reset _LastError
bool an_OK_flag = OrderModify( ... ); // XTO call w ex-post _LastError
int anErrorSTATEtoHANDLE = GetLastError(); /* get a value of the _LastError
+ implicit post-reset _LastError */
// -------------------------------------------- // HANDLE ERROR-STATE(s)
switch( anErrorSTATEtoHANDLE ){
case ERR_NO_ERROR: break;
case ERR_NO_RESULT: ...
break;
case ERR_INVALID_TRADE_PARAMETERS: ...
break;
case ERR_SERVER_BUSY: ...
break;
case ERR_BROKER_BUSY: ...
break;
case ERR_TOO_MANY_REQUESTS: ...
break;
case ERR_TRADE_MODIFY_DENIED: ...
break;
...
default: break;
}
// -------------------------------------------- // FIN __________________________
This makes your code robust against any kind of some "forgotten" ( coincidentally un-reset ) last error ( which was not crashing your code-execution at the place, where such error has appeared but ... ) which would trigger later an unwanted behaviour in the "next" error-handling section, thus potentially sending you an email also in cases, where the email-signal was not present, but the "forgotten" ( un-reset ) value inside the _LastError system register co-incidentally matched the error-handling case, resulting in sending the said email ( as if there were an email-signal present ( which was not, as described above ).