Discussing the article: "Mastering Log Records (Part 8): Error Records That Translate Themselves"

New comment
 

Check out the new article: Mastering Log Records (Part 8): Error Records That Translate Themselves.

In this eighth installment of the Mastering Log Records series, we explore the implementation of multilingual error messages in Logify, a powerful logging library for MQL5. You’ll learn how to structure errors with context, translate messages into multiple languages, and dynamically format logs by severity level. All of this with a clean, extensible, and production-ready design.

At this point in the journey, it's no surprise that logging isn't just about recording events. It's about accurately capturing what your EA is trying to tell you in the midst of the whirlwind of ticks, decisions and uncertainties that define everyday algorithmic trading.

During my day-to-day use of Logify, I noticed something that bothered me: the error handling was still superficial. Even with a robust formatting structure, the logs still only displayed the raw error code, without any indication of what it actually meant. Something like:

logify.Error("Failed to send sell order", "Order Management", "Code: "+IntegerToString(GetLastError()));
// Console:
// 2025.06.06 10:30:00 [ERROR]: (Order Management) Failed to send sell order | Code: 10016

The result? A nebulous message. We know where the error happened, but not why. And who has ever had to investigate dozens of MQL5 codes in the documentation? I used to do it myself quite often: once I had the error code, I had to search the documentation to find out what really happened. It was out of this real friction that I came up with the idea: what if Logify could interpret the error for me? What if, instead of just giving me the code, it also gave me its meaning in a clear, contextualized way, ready to be logged?

Author: joaopedrodev

 
Both libraries you created are excellent, thanks for the code.
 
Thank you, I'm happy to help. Any suggestions for improvement, please contact me!
 
joaopedrodev #:
Thank you, I'm happy to help. Any suggestions for improvement, please contact me!
What should I do if the logging is very frequent but I want to avoid repeated prints? For example, when a trade opening signal is detected, but the spread is too large and persists for dozens of seconds—if logging is used, it would print at least dozens or even hundreds of times. How can this situation be resolved? I know one solution is to use a variable to ensure the log is only displayed once, but it would be better if the logging library itself could handle this. Could you provide some suggestions?
 

I compiled the logging library Logify, and after MT5 build 5100, there are several compilation errors related to types in  CLogifyHandlerDatabase::Query . I believe you should have already resolved this issue.
 
Thanks for the suggestions, I will address them in future articles.
 
joaopedrodev #:
Thanks for the suggestions, I will take them up in future articles.

A small idea about the languages.

Perhaps arrange the original English messages in such a way that they can easily be copied and pasted into a translator (deepl.com or translate.google.com) and the result placed back into the programme. This makes it easy for anyone to set up the programme in their own language.

Deeple recognises 36 languages, Google even about 130.

New comment