再利用された例外タイプは、使い捨てのものよりも優先されるべきですか？

Doorが管理しているsがあるとしDoorServiceます。DoorServiceデータベースに格納されているドアを開く閉じてロックを担当しています。

public interface DoorService
{
    void open(Door door) throws DoorLockedException, DoorAlreadyOpenedException;

    void close(Door door) throws DoorAlreadyClosedException;

    /**
     * Closes the door if open
     */
    void lock(Door door) throws DoorAlreadyLockedException;
}

lockメソッドにはがありDoorAlreadyLockedException、openメソッドにはがありDoorLockedExceptionます。これはオプションですが、他にも可能なオプションがあります。

1）DoorLockedExceptionすべてに使用すると、lock()通話で例外をキャッチするときに少し面倒です

try
{
    doorService.lock(myDoor);
}
catch(DoorLockedException ex) // door ALREADY locked
{
    //error handling...
}

2）2つの例外タイプがDoorLockedExceptionあり、DoorAlreadyLockedException

3）2つの例外タイプがありますが、 DoorAlreadyLockedException extends DoorLockedException

どちらが最善の解決策であり、それはなぜですか？

フロー制御に例外を使用することで人々が大きな問題を起こすことは知っていますが、それがここでの最大の問題ではありません。巨大なコマンドクエリ分離違反が見つかりました。しかし、それは最悪ではありません。

いいえ、最悪はここです。

/**
 * Closes the door if open
 */

ドアの状態についてのあなたの仮定が間違っているがlock()、あなたのためにそれを修正するだけなのに、なぜ他のすべてが爆破するのですか？これはドアを開けるのをロックすることを不可能にすることを忘れてください、それは絶対に可能で、時々役に立ちます。ここでは問題はありません。間違った仮定に対処するために2つの異なる哲学を混在させていることです。それは紛らわしいです。それをしないでください。同じ命名スタイルで同じレベルの抽象化ではありません。わぁ！それらのアイデアの1つを外に持ち出してください。ドアサービスメソッドはすべて同じように動作するはずです。

コマンドクエリの分離違反に関しては、ドアが閉じているか開いているかを確認するためにドアを閉める必要はありません。私はただ尋ねることができるはずです。ドアサービスは、ドアの状態を変更せずにそれを行う方法を提供していません。これは、値を返すコマンド（CQSが何であるかについてよくある誤解）に比べて、これをはるかに悪化させます。ここでは、状態変更コマンドがクエリを実行する唯一の方法です。わぁ！

例外はステータスコードよりもコストが高いので、それは最適化の話です。十分な速さで十分です。本当の問題は、人間が典型的なケースの例外を期待しないことです。あなたが好きなすべての典型的なものについて議論することができます。私にとって大きな問題は、使用するコードをどの程度読みやすくするかです。

ensureClosed(DoorService service, Door door){
  // Need door closed and unlocked. No idea of its state. What to do?
  try {
    service.open(door)
    service.close(door)
  } 
  catch( DoorLockedException e ){
    //Have no way to unlock the door so give up and die
    log(e);
    throw new NoOneGaveMeAKeyException(e);      
  }
  catch( DoorAlreadyOpenedException e ){
    try { 
      service.close(door);
    }
    catch( DoorAlreadyClosedException e ){
      //Some multithreaded goof has been messing with our door.
      //Oh well, this is what we wanted anyway.
      //Hope they didn't lock it.
    }
  }
}

このようなコードを書かないでください。方法isLocked()など教えてくださいisClosed()。それらを使用して、自分ensureClosed()でensureUnlocked()読みやすいメソッドを作成できます。投稿条件に違反した場合にのみスローするもの。もちろん、あなたがすでにそれらを書いてテストしたことがあると思います。状態を変更できないときにスローするものと一緒に混ぜないでください。少なくとも、区別しやすい名前を付けてください。

_{何をするにしても、何も呼ばないでくださいtryClose()。それはひどい名前です。}

用としてDoorLockedExceptionも持つ対だけでDoorAlreadyLockedException病気がこれを言う：それは使用してコードについてのすべてです。使用するコードを記述し、作成している混乱を確認せずに、このようなサービスを設計しないでください。使用するコードが少なくとも読めるようになるまで、リファクタリングと再設計を行います。実際、使用コードを最初に記述することを検討してください。

ensureClosed(DoorService service, Door door){
  if( !service.isClosed(door) ){
    try{
      service.close(door);
    }
    catch( DoorAlreadyClosedException e ){
      //Some multithreaded goof has been messing with our door.
      //Oh well, this is what we wanted anyway.
      //Hope they didn't lock it.
    }
  } else {
    //This is what you wanted, so quietly do nothing. 
    //Why are you even here? Who bothers to write empty else conditions?
  }
}

ensureUnlocked(DoorService service, Door door){
  if( service.islocked(door) ){
    throw new NoOneGaveMeAKeyException(); 
  }
}

フロー制御にはさまざまな例外タイプが使用されていることを区別DoorLockedExceptionしてDoorAlreadyLockedException示唆しています。これは、すでにアンチパターンと広く見なされている手法です。

この害のないものに対して複数の例外タイプがあることは不合理です。追加の利点は、追加の複雑さを上回らない。

DoorLockedExceptionすべてに使用するだけです。

さらに良いことに、何もしないでください。ドアがすでにロックされている場合、lock()メソッドが完了してもドアは正しい状態のままです。目立たない状況では例外をスローしないでください。

それでも不快な場合は、メソッドの名前を変更してくださいensureDoorLocked()。

この質問の主題は、「リサイクルされた例外のタイプは、使い捨ての例外のタイプよりも優先されるべきか？」です。回答だけでなく、質問の詳細でも無視されているようです（質問の詳細に対する回答でした）。

回答者が提供したコードに対するほとんどの批判に同意します。

しかし、見出しの質問に対する答えとして、「使い捨ての例外」よりも「リサイクルされた例外」の再利用を強く好むべきだと私は言うでしょう。

例外処理のより一般的な使用では、例外が検出されてスローされる場所と、例外がキャッチされて処理される場所との間のコードに大きな距離があります。つまり、例外処理でプライベート（モジュラー）型を使用しても、通常はうまく機能しません。例外処理を備えた典型的なプログラム-例外が処理されるコード内のトップレベルの場所がいくつかあります。そして、それらはトップレベルの場所であるため、特定のモジュールの狭い側面について詳細な知識を持つことは困難です。

代わりに、いくつかの高レベルの問題に対する高レベルのハンドラーが含まれる可能性があります。

詳細なカスタム例外クラスを使用する唯一の理由は、サンプルで理にかなっているように思われます。これは（そして、ここでは他の回答者をインパクトしています）-通常の制御フローでは例外処理を使用しないでください。

未踏の代替品。あなたはあなたのクラスで間違ったものをモデル化しているかもしれません、代わりにこれらを持っていたらどうでしょうか？

public interface OpenDoor
{
    public ClosedDoor close();
    public LockedDoor lock();
}

public interface ClosedDoor
{
    public OpenDoor open();
    public LockedDoor lock();
}

public interface LockedDoor
{
    // ? unlock? open?
}

現在、エラーであるものを試みることは不可能です。例外は必要ありません。

例を批判するのではなく、元の質問に答えます。

簡単に言えば、クライアントがケースごとに異なる反応をする必要があると思われる場合は、新しい例外タイプを保証します。

複数の例外タイプを使用することを決定したにもかかわらず、クライアントがそれらに共通のcatch句を作成したい場合があると予想する場合は、おそらく両方が拡張する抽象スーパークラスを作成する必要があります。

これは疑似コードですが、私が意味することは理解できると思います。

public interface DoorService
{
    // ensures the door is open, uses key if locked, returns false if lock without a key or key does not fit
    bool Open(Door door, optional Key key) throws DoorStuckException, HouseOnFireException;

    // closes the door if open. already closed doors stay closed. Locked status does not change.
    void Close(Door door) throws throws DoorStuckException, HouseOnFireException;

    // closes the door if open and locks it
    void CloseAndLock(Door door, Key key) throws DoorStuckException, HouseOnFireException;
}

はい、本当に例外的なものに例外を使用する場合、例外タイプの再利用は理にかなっています。本当に例外的なことは、主に分野横断的な懸念だからです。例外を基本的に制御フローに使用していたため、これらの問題が発生しました。