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 ).