記事「ログレコードをマスターする（第8回）：自己翻訳するエラーレコード」についてのディスカッション

新しいコメント
 

新しい記事「ログレコードをマスターする（第8回）：自己翻訳するエラーレコード」はパブリッシュされました:

「ログレコードをマスターする」第8回では、MQL5向けの強力なログライブラリであるLogifyにおける多言語エラーメッセージの実装について探っていきます。本記事では、コンテキストを含めたエラー構造の作り方、メッセージを複数言語に翻訳する方法、そして重大度レベルに応じたログの動的フォーマット方法について学びます。これらはすべて、クリーンで拡張可能であり、本番環境でも利用可能な設計にします。

ログ記録が単なるイベントの記録にとどまらないことは、もはや驚くことではありません。ログは、EAが日々のティック、意思決定、そして不確実性の中で何を伝えようとしているかを正確に捉えるための手段です。

日常的にLogifyを使っていて気になったのは、エラーハンドリングがまだ表層的である点です。堅牢なフォーマットがあっても、ログにはエラーコードだけが表示され、それが何を意味するのかは分かりませんでした。たとえば以下のようになります。

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

その結果、曖昧なメッセージしか得られないのです。どこでエラーが発生したかは分かりますが、なぜ発生したのかはわかりません。MQL5のドキュメントで数十ものコードを調べなければならなかった経験は、誰にでもあるでしょう。私自身もよくそうしていました。エラーコードが分かったとしても、実際に何が起きたのかを知るためにはドキュメントを検索する必要がありました。この実際のフラストレーションからひとつのアイデアが生まれました。「もしLogifyがエラーを解釈してくれたらどうだろう？」「コードだけでなく、その意味を文脈付きで明確に表示してくれたら？」


作者: joaopedrodev

 
あなたが作ったライブラリーはどちらも素晴らしい。
 
ありがとうございます。改善の提案があれば、ご連絡ください！
 
joaopedrodev #:
ありがとうございます。改善提案があれば、ご連絡ください！
ロギングの頻度が非常に高いが、繰り返しのプリントを避けたい場合はどうすればよいですか？例えば、取引開始シグナルが検出されたものの、スプレッドが大きすぎて何十秒も持続している場合、ロギングを使用すると、少なくとも何十回、あるいは何百回も印刷されてしまいます。この状況を解決するにはどうすればよいでしょうか？変数を使用して、ログが一度しか表示されないようにするのが一つの解決策であることは知っていますが、ロギング・ライブラリ自体がこれを処理できればより良いでしょう。何かご提案いただけますか？
 

ロギングライブラリ Logify をコンパイルしたところ、MT5 ビルド 5100 以降、CLogifyHandlerDatabase::Query の 型に関連するコンパイルエラーがいくつか発生しました。この問題はすでに解決されているはずです。
 
ご指摘ありがとうございます。今後の記事で取り上げさせていただきます。
 
joaopedrodev #:
ご提案ありがとうございます。今後の記事で取り上げさせていただきます。

言語についてのちょっとしたアイデア。

オリジナルの英語のメッセージを、翻訳機（deepl.comやtranslate.google.com）に簡単にコピー＆ペーストできるように並べ、その結果をプログラムに戻す。これにより、誰でも簡単に自分の言語でプログラムをセットアップすることができる。

Deepleは36言語、Googleは約130言語を認識する。

新しいコメント