1

double のシーケンスを特定の形式でファイルに保存するライブラリを作成しているとします。この形式では、double が単調増加している必要があります。

現在、一部のユーザーはマニュアルを注意深く読んだり、次のようなバグのあるフロントエンドを作成したりしません。

store(3.0)
store(3.1)
store(0.3)
store(7.8)

図書館ができることは

  1. を呼び出すとエラーになりstore(0.3)ます。
  2. 実際に など、適切な推測を行ってエラーを修正してくださいstore(3.3)。
  3. エラーを修正し、メッセージを に書き込んでくださいstderr。
  4. [...]

(1) の利点は、ユーザーがそれを見逃すことがないことです。ただし、コードが長時間実行された場合 (これは私のコンテキストでは通常のケースです)、ユーザーはプログラムの中止にあまり満足しません。(2) これをなくしますが、ライブラリの誤用を助長する可能性があります。

ある言語を支持するポリシーはありますか?

4

1 に答える 1

1

使用する言語に関係なく、私の一般的なアドバイスは、常にすぐに失敗することです。これにより、エラーが問題の実際の原因にローカライズされます。つまり、エラーまたは例外をスローして救済します (言語によっては、プログラマーが例外をキャッチできる可能性があります)。同様に、チェックされた例外を持つ一部の言語では、プログラマーが不正な入力のチェックを追加する必要がある場合があります。

その理由は単純です。エラーが発生する問題の実際の原因から離れれば離れるほど、プログラムのデバッグが難しくなります。プログラマーが意図したものではなく3.3( . また、これらの値のソースが何らかのソート アルゴリズムにバグがあった可能性もあります。この場合、ライブラリが失敗しないという事実は、ソート アルゴリズムをデバッグして、失敗の本当の原因を特定することを難しくするだけです。0.33.3

また、コードの単体テストを試みると地獄に落ちます。失敗するはずのコードが、必ずしも適切な場所で失敗するとは限りません。これにより、コードが魔法のようになり、開発プロセスの一部として管理することがはるかに難しくなります。

単純に失敗して、ユーザーまたはクライアント プログラムに対話を最初からやり直すよう強制する代わりの方法があります。失敗した後もライブラリが一貫した状態のままになるように、トランザクションの方法で物事を行うことができます。最後の有効な入力 (たとえば)。ただし、これは、データの一貫性を確保するために、適切なロールバック セマンティクスで実装する必要があります。

要約すると、早く失敗し、早く失敗することです。

于 2012-08-31T13:48:16.797 に答える