3

時間のかかるコードをバックグラウンドで実行すると、do ファイルの先頭にある小さな構文ミスが原因で、コードの 10% も実行されないことがよくあります。

最初の間違いが最後の計算に影響しない場合があるため、do ファイルの残りの部分も実行することをお勧めします。

4

2 に答える 2

6

(バージョン 2)

Stata に間違いを無視してもらいたいというのは、それ自体が間違っている可能性があります。

  1. do ファイルの早い段階で間違いがあった場合、通常はその後の処理に影響があります。

  2. Stata を思い通りに動作させたとします。Stata が何か重要なことを無視したのか、些細なことを無視したのか、どうやってわかりますか? 些細なことを無視した場合は、簡単に修正できるはずです。重要なことを無視したとしたら、それは間違った決定でした。

今はもっと建設的になりましょう。のヘルプdoは、nostopオプションがあることを示しています。使用方法には十分注意する必要がありますが、ここで役立ちます。

のコンテキストは、do, nostopまさに OP のコンテキストです。人々は do-file を持っていましたが、大きなデータセットや多くの重い計算のために長い時間がかかると予想されることが多く、歴史的に「一晩」または「昼食に行っている間」にそれらを設定していました。その後、DO ファイルが最初のエラーですぐに終了してしまったことに苛立ち、特にエラーが些細なものである場合は苛立ちます。したがって、のアイデアdo, nostopはdoできる限り多くのことですが、デバッグの補助としてです。たとえば、さまざまな場所で変数名を間違えたとします。あなたは後でgenerate Y参照しますがy、存在しません。対応するエラー メッセージがファイル全体に散らばっているはずですが、これは修正できます。ここでは、エラー メッセージが重要です。

do ファイルの重要な点は、正しく作成されれば多くの時間を節約できるということですが、最初から do ファイルを正しく作成することが常に簡単であるとは誰も約束していませんでした。

私の確固たるアドバイスは次のとおりです。バグを修正します。それらを無視しようとしないでください。

PScaptureは別の回答で言及されました。capture精神的には似ているように見えるかもしれませんが、似たようなスタイルで使用するのは悪い考えかもしれません。

captureエラーメッセージを食べるので、ユーザーには表示されません。デバッグの場合、これは必要なものとは逆です。

captureは実際にはプログラマーのコマンドであり、その使用法は、プログラマーがユーザーに代わって賢く、それについて静かにしている場合です。

たとえば、指定された変数が数値または文字列であるとします。数値の場合は、A; を実行する必要があります。文字列の場合は、B を実行する必要があります (A または B は「何もない」可能性があります)。このような分岐が存在する可能性があります。

  capture confirm str variable myvar 
  if _rc { /// it's numeric 
       <do A> 
  } 
  else { 
       <do B> 
  }

そうでなければ、capture予測可能な問題が発生した場合に対処するためのものです。バグを無視するためのものではありません。

于 2013-09-05T00:31:01.077 に答える
1

ハングアップしているコマンドが 2 つしかなく、それ以外の場合は後の計算では重要でない場合は、いつでもcapture(インライン プレフィックスとして、またはブロック コマンドとして、使用を参照help capture) を使用して、停止するコマンドを実行するようにプログラムを強制することができます。プログラム。

しかし、この do ファイルの書き方と実行方法に関する Nick の一般的なコメントを反映して、適用する場所にも同様に注意してくださいcapture。または、さらに良いのは、問題を引き起こしている行をプログラムから削除するだけで、とにかく必要がないように見えることです。

于 2013-09-05T03:30:17.740 に答える