0

現在作業中のプロジェクトでは、エラーと例外を区別するのに少し問題があります。エラーと例外の私の定義も完全に正しいです)。"エラー"になる確率が高い "例外"を処理する

私が混乱しているところは、例外がエラーになるのを防ぐ方法です。私はたくさんの関係を保持するモデルクラスを持っているとします。モデルにはModel.AddRelationship()メソッドがあり、モデル内に循環参照を作成する可能性があります。ユーザーが循環参照を作成するUIに関係を追加しようとすると、それをブロックして理由を説明する必要があります。だから、私はいくつかのオプションをつかんできました:

// In the UI when the user tries to add a relationship: 

var newRelationship:Relationship = new Relationship(); 

if(Model.AddingThisWillCreateACircularReference(newRelationship)) 
{ 
    this.warnUserAboutCircularReference(); 
} 
else 
{ 
    Model.AddRelationship(relationship); 
} 

私の一部は、それを呼び出す前に呼び出しを検証する必要があると思います。結局のところ、関係を追加するのはプログラムをクラッシュさせるものではなく、他のコードが無限ループになる操作を実行するときです。一方、私はすべての回で安全な状態でモデルを維持する義務を感じる、と私はこのような何かを行うことによって、悪い循環参照の状況に対処するために、開発者を強制する必要があること:

// In the model itself: 

public function AddRelationship(relationship:Relationship):Boolean 
{ 
    var success:Boolean = true; 

    if(this.AddingRelationshipWillCreateACircularReference(relationship)) 
    { 
     success = false; 
    } 
    else 
    { 
     this.addRelationship(relationship); 
    } 

    return success; 
} 

そのように彼らを追加することができないことを知っているか、関係が単純に追加されません。それはまた間違っていると感じる。誰か私にいくつかの明確さを与えるのに役立つかもしれない考えを私に与えることができますか?前もって感謝します。

答えて

2

慣例として、「エラー」は、アプリケーションがまったく処理できない状態(ディスククラッシュ)を示しています。例外は、アプリケーションがシャットダウンする前に回復しようとするか、クリーンアップするなどの異常な状況です。

私は、2つ以上のタイプの例外を分割すると便利です。アプリケーションの誤った設定や誤った取り扱い(つまり、検証例外)によって引き起こされるビジネス例外と、アプリケーション自体に起因しない条件データベースへの接続の切断、ソケットのタイムアウトなど)。

あなたの疑問にお答えします。モデルは常に安定していなければならず、できるだけ低レベルで再利用を促進する必要があります。したがって、検証をモデルに入れ、操作を試し、失敗した場合はユーザーに通知します。自分の言語で例外が発生していない場合は、結果の状態を示す「結果コード」を返します(0 - 成功、1-循環依存、2 - 不明理由など)。

1

私は通常、ユーザーが「エラー」を修正できる場合は、例外をスローしないというルールを使用します。 「エラー」が本当に予期せぬものであり、ユーザが入力を修正してそれを越えてしまうことができない場合、例外がスローされるはずです。

ファイルやフォルダのパスが存在することを確認するためのコードを書くなど、問題を積極的にチェックしている場合は、状況を適切に処理して例外をスローせずにユーザーに提示する必要があります。