Discussion of article "Error Handling and Logging in MQL5"
Good afternoon!
Why didn't you consider the question "Processing of trade server return codes" ?
This is much more IMPORTANT than everything in your article.
Good afternoon!
Why didn't you consider the question "Processing of trade server return codes" ?
This is much more IMPORTANT than everything in your article.
First of all, read the whole article. If you don't understand it, then read it again and again until you fully understand it. Only then you will realise that your message has nothing to do with the topic of the article.
The article should have been called not"Error handling and logging in MT5",
but "Processing of OWN errors and logging in MT5"!
Good afternoon!
Why didn't you consider the question "Processing of trade server return codes" ?
It is much more IMPORTANT than everything in your article.
Mikhail, why don't you just write such an article? It's a ready-made topic! :)
I didn't think that this topic is more important than everything in the article. If you think so - well, just do it, why scold me for not doing it?
In fact, I did not try to consider this point in detail, because I wanted to touch upon more general issues. So we may get into a detailed consideration of error codes returned by standard language functions. For example, as another topic of the article - "Handling errors occurring when working with graphical objects in MQL5".
My goal was not the same. But yes, a month after writing the article, I see that it turned out "so-so". Well, I will try to be better in the future.
Why don't you just write an article like this? It's a ready-made topic! :)
In fact, I didn't want to discuss this point in detail, because I wanted to touch upon more general issues. So we can go into a detailed consideration of error codes returned by standard language functions. For example, as another topic of the article - "Handling errors occurring when working with graphical objects in MQL5".
My goal was not the same. But yes, a month after writing the article, I see that it turned out "so-so". Well, I will try to be better in the future.
Sergei!
It's all right, but I would call the article
"Advanced methods of debugging Expert Advisors in MT5 with logging."
Because when the Expert Advisor is debugged, there are no more errors,
but the return codes of the trade server may be full of errors,
which need to be processed just in the Expert Advisor's normal mode.
Sergei!
Everything is fine, but I would call the article
"Advanced methods of debugging Expert Advisors in MT5 with logging."
But error handling is not debugging :)
Or do you want to say that, for example, processing the error "insufficient funds" (which is mentioned in the article as an example) is debugging?
But error handling is not debugging :)
Or do you want to say that, for example, processing the error "insufficient funds" (which is the example mentioned in the article) is debugging?
"Insufficient funds" is not an error, but a message to you (to the expert about the state of your account) and
this is a STANDARD handled situation. And a normal developer MUST, before making a transaction or placing an order.
order to verify the availability of funds.
//+------------------------------------------------------------------+ //| Expert Check money function| //+------------------------------------------------------------------+ bool CheckMoney( const long volume ) { double a_go = SymbolInfoDouble( _Symbol, SYMBOL_MARGIN_INITIAL ) * double(volume); double free_margin = ( AccountInfoDouble( ACCOUNT_FREEMARGIN ) / 100 ) * 90; //--- if ( a_go <= free_margin ) { return( true ); } Print( "Check Money: Not Enough Funds!" ); return( false ); }
"Insufficient funds" is not an error but a message to you (to the Expert Advisor about the state of your account) and
this is a STANDARD processed situation.
But it is not a debugging moment either. Call it what you want, but it must be processed (and as I see it, we agree on this). In my understanding, it is an erroneous situation relative to the normal course of things. After all, the expert may assume that the means are sufficient. And if it is not checked and processed in any way, it will turn out to be nothing.
Just like, for example, the error of opening a file due to its absence - on the one hand it is a standard situation that needs to be handled, but on the other hand it is an error of assuming that the file is there and we can work with it.
And once again: in this article I tried to consider issues of error handling in the process of programme operation rather than issues of software debugging. This is another topic altogether and correlates with the article only within the framework of logging (and that only partially).
And it was not my goal to consider specific errors (be it trade server return codes, or, as I said above, for example, possible errors when working with graphical objects). Just general methods that are applicable to errors (or standard situations, if you like) that are returned by the trade server as well.
I am sorry if my message remained unclear. Hopefully, everything will fall into place now.
this is a STANDARD handled situation. And a normal developer MUST, before making a transaction or placing an order.
or placing an order to verify the availability of funds.
Alas, I have to ask: did you read the article or did you just run through it and judge? I spoke about the preliminary checks in the article (I repent, I did not speak specifically about the check of funds, but I thought it was clear). And it is not a bad idea to handle a possible error "insufficient funds" even after trying to open a trade, even if we made this check before. Anything can happen in the time between the "before" check and the immediate attempt to open.
Alas, I have to ask: did you read the article, or did you just run through it and judge? I spoke about preliminary checks in the article (I repent, I did not speak specifically about checking funds, but I thought it was clear). And handling a possible error "insufficient funds" even after trying to open a trade is not the worst idea, even if we made this check before. Anything can happen in the time between the "before" check and the immediate attempt to open.
Sergey!
That's what trade server return codes are for such situations.
Example: You have checked the availability of free funds and received an affirmative result.
You send an order, but it was not accepted (as you said: "What can happen"),
so the trading server will give you the error "Insufficient funds" in the return code.
And it turns out that it makes absolutely "no difference" how many times you check for the error.
between your check (CheckMoney) and the trade server's return code!
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
New article Error Handling and Logging in MQL5 has been published:
This article focuses on general issues linked to handling software errors. Furthermore, the logging term is brought up and the examples of logging implementation with MQL5 tools are shown.
During the operation of most programs, errors may occasionally occur. Their adequate processing is one of the important aspects of a high-quality and sustainable software. This article will cover main methods of error handling, recommendations for their use, as well as logging via MQL5 tools.
Error handling is a relatively difficult and controversial subject. There are many ways of error handling, and each of them has certain advantages and disadvantages. Many of these methods can be used together, but there is no universal formula — each specific task requires an adequate approach.
Logging with MQL5 tools
Log files are normally created by the program specifically for programmers to facilitate the search of failure/error reasons and to evaluate the system's condition at a specific moment in time etc. In addition to that, logging can be used for software profiling.
Levels of logging
Messages received in the log files often carry different criticality and require different levels of attention. Logging levels are applied to separate messages with various criticality from each other and to have the ability to customize the criticality degree of displayed messages. Several logging levels are normally implemented:
Author: Sergey Eremin