記事"MQL5でのエラー処理とロギング"についてのディスカッション

新しいコメント
 

新しい記事 MQL5でのエラー処理とロギング はパブリッシュされました:

この記事では、ソフトウェアにおける一般的なエラー処理の問題について述べていきます。また、ロギングについて言及し、MQL5のツールによるデータロガーの実装例をデモンストレーションします。

void SetLevelsメソッド(const ENUM_LOG_LEVEL logLevel, const ENUM_LOG_LEVEL notifyLevel)。 ロギングレベルを設定します。

const ENUM_LOG_LEVEL logLevel — ロギングレベル以上のメッセージはログファイル/ジャーナルに保存されます。デフォルト = LOG_LEVEL_INFO.

const ENUM_LOG_LEVEL notifyLevel — ロギングレベル以上のメッセージは通知として表示されます。デフォルト = LOG_LEVEL_FATAL.

両方に可能な値：

  • LOG_LEVEL_DEBUG,
  • LOG_LEVEL_INFO,
  • LOG_LEVEL_WARNING,
  • LOG_LEVEL_ERROR,
  • LOG_LEVEL_FATAL.


作者: Sergey Eremin

 

こんにちは！

なぜ「トレードサーバーのリターンコードの 処理」という質問を考慮しなかったのですか？

これは、あなたの記事のすべてよりもはるかに重要です。

 
Михаил:

こんにちは！

なぜ「トレードサーバーのリターンコードの 処理」という質問を考慮しなかったのですか？

これは、あなたの記事のすべてよりもはるかに重要です。

まず、記事全体を読んでください。もし理解できないのであれば、完全に理解できるまで何度も読み直してください。そうして初めて、あなたのメッセージが記事で触れられているトピックとは何の関係もないことに気づくでしょう。
 
Karputov Vladimir:
まずは記事を全部読んでください。理解できないなら、完全に理解できるまで何度も読み返すことだ。そうして初めて、あなたのメッセージが記事のトピックとは何の関係もないことに気づくでしょう。

記事のタイトルは「 MT5におけるエラー処理と ロギング」ではなく、「 OWNエラーの 処理」とすべきだった、

しかし、「MT5におけるOWNエラーの処理とロギング」とすべきでした！

 
Михаил:

こんにちは！

なぜ「トレードサーバーのリターンコードの 処理」という質問を考慮しなかったのですか？

それはあなたの記事のすべてよりもはるかに重要です。

ミハイル、なぜそのような記事を書かないのですか？すぐにできる話題だよ！:)

私は、このトピックが記事のすべてよりも重要だとは思っていない。そう思うなら、そうすればいいじゃないか。


実際、私はもっと一般的な問題に触れたかったので、この点について詳しく考察しようとはしませんでした。というわけで、標準言語関数が返すエラーコードについての詳細な考察に入るかもしれない。例えば、「MQL5でグラフィカル・オブジェクトを操作するときに発生するエラーの処理」という記事の別のトピックとして。

私の目標は同じではなかった。しかし、記事を書いてから1ヶ月経ってみると、「まあまあ」の出来になっている。まあ、今後はもっと良くなるように努力しよう。

 
Sergey Eremin:

こういう記事を書けばいいじゃないか。できあいの話題なんだから！:)

実は、もっと一般的な問題に触れたかったので、この点については詳しく説明したくなかった。というわけで、標準言語関数が返すエラーコードについての詳細な考察に入ることができる。例えば、記事のもう一つのトピックである「MQL5でグラフィカル・オブジェクトを操作するときに発生するエラーの処理」として。

私の目標は同じではなかった。しかし、記事を書いてから1ヶ月経ってみると、「まあまあ」の出来になっている。まあ、今後はもっと良くなるように努力するよ。

セルゲイ

それはいいのですが、私はこの記事をこう呼びたいと思います。

"MT5でExpert Advisorを ロギングしてデバッグする 高度な方法"

Expert Advisorがデバッグされると、エラーはなくなります、

しかし、トレードサーバーのリターンコードはエラーだらけかもしれません、

Expert Advisorの通常モードで処理する必要があります。

 
Михаил:

セルゲイ

すべて順調ですが、記事をこう呼ぶことにします。

"ロギングを使用したMT5のExpert Advisorの 高度なデバッグ 方法"

しかし、エラー処理はデバッグではありません :)

それとも、例えば「資金不足」というエラー（これは記事の中で例として挙げられています）を処理することがデバッグだと言いたいのですか？

 
Sergey Eremin:

しかし、エラー処理はデバッグではない :)

それとも、例えば「資金不足」というエラー（これは記事で言及されている例です）を処理することがデバッグだと言いたいのですか？

「資金不足」はエラーではなく、あなたへの（あなたの口座の状態についての専門家への）メッセージです。

これは標準的な処理です。そして、通常の開発者は、取引や注文をする前に、資金が利用可能かどうかを確認しなければなりません。

を注文して、 資金の利用可能性を確認しなければなりません。

//+------------------------------------------------------------------+
| エキスパート・チェック・マネー機能|
//+------------------------------------------------------------------+ 
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( "小切手代：資金不足！" );
  return( false );
}
 
Михаил:

「資金不足」はエラーではなく、あなたへのメッセージです。

これは標準的な処理状況です。

しかし、これはデバッグの瞬間でもありません。どう呼ぼうと勝手ですが、これは処理されなければなりません（そして、私の見るところ、私たちはこれに同意しています）。私の理解では、それは通常の経過に照らし合わせた誤った状況である。結局のところ、専門家はその手段で十分だと思い込んでいるのかもしれない。そして、それをチェックし、何らかの処理をしなければ、何もないことが判明する。

例えば、ファイルが存在しないためにファイルを開くことができないというエラーのように、一方では処理しなければならない標準的な状況であるが、他方ではファイルが存在し、それを使って作業できると思い込んでいるエラーなのである。


もう一度言う。この記事では、ソフトウェアのデバッグの問題ではなく、プログラムの動作過程におけるエラー処理の問題を考えようとした。これは全く別のトピックであり、ロギングの枠組みの中でだけ（それも部分的にだけ）この記事と関連している。
また、特定のエラー（取引サーバーのリターン・コード であったり、上で述べたように、例えばグラフィカル・オブジェクトを操作するときに起こりうるエラーであったり）を検討することが私の目的ではなかった。ただ、トレードサーバーが返すエラー（あるいは標準的な状況）にも適用できる一般的な方法を考えただけです。

私のメッセージが不明瞭なままだったら申し訳ありません。これですべてがうまくいくことを願っています。

 
Михаил:

これは標準的な処理状況である。そして、通常の開発者は、取引や注文を行う前に、次のことを行わなければなりません(MUST)。

そして、通常の開発者は、取引や注文を行う前に、資金が利用可能かどうかを確認しなければなりません。

あなたは記事を読んだのですか、それとも目を通しただけで判断したのですか？私は記事の中で、事前のチェックについて話した（繰り返すが、資金のチェックについて 具体的に話したわけではないが、明確だと思った）。そして、たとえ事前にこのチェックを行ったとしても、取引を開始しようとした後でも、「資金不足」というエラーが発生する可能性があることに対処するのは悪い考えではない。資金不足」というエラーは、たとえ事前にチェックをしていたとしても、取引開始後に発生する可能性があります。

 
Sergey Eremin:

あなたは記事を読んだのですか、それとも目を通しただけで判断したのですか？私は記事の中で、事前のチェックについて話しました（繰り返しになりますが、資金のチェックについて 具体的に話したわけではありません。）また、取引開始後に「資金不足」というエラーが発生する可能性がある場合、たとえ事前にこのチェックを行ったとしても、それを処理することは最悪のアイデアではありません。取引開始前」のチェックと取引開始直後のチェックの間には、何が起こるかわかりません。

セルゲイ！

それがトレードサーバーのリターンコード です。

例フリーファンドの利用可能性をチェックし、肯定的な結果を受け取った。

注文を出したが受理されなかった、

そのため、取引サーバーはリターンコードに「資金不足」というエラーを表示します。

そして、このエラーを何度チェックしても、まったく「違いがない」ことがわかります。

あなたの小切手（CheckMoney）と取引サーバーのリターン・コードとの間で！

12
新しいコメント