インターフェイスメソッドで常に「例外をスローする」と宣言しますか？

Question

インターフェイスがあり、そのメソッドがどのように実装されるのかわからない場合（つまり、他のユーザーが拡張するライブラリ）、そのメソッドの実装が例外を起こしやすいかどうかをどのように知ることができますか？あなたは、実装を知らないので、すべてのインタフェースメソッドに "例外をスロー"すると宣言するだけですか？

たとえば、私はhttpクライアントを作っています。このライブラリは、httpリクエスト文字列を表しRequestインターフェースを持っています

public interface Request 
{ 
    String asString(); // no "throws" here 
} 

public final class AssembledRequest implements Request 
{ 
    // ... 
    public AssembledRequest(Method method, Url url, Headers headers, Body body) { 
     // ... 
    } 
    public String asString() { 
     // ... 
    } 
} 

また、このRequestインタフェースを使用していますResponseクラスを、持っています。 私自身の実装（AssembledRequest）は例外をスローしません。文字列の束をアセンブルするだけで、ほとんどの実装でおそらく何もスローされません。

しかし、ユーザがのファイルを読み込む方法でRequestを実装したい場合はどうなりますか？その後、我々はIOExceptonを扱っており、ユーザーがそのような例外を処理することは非常に難しいでしょう。 No throws...が宣言されているので、メソッド内で処理する必要があります。ノーノーです。キャッチして再スローする必要があるため、アプリケーションの上部にバブルアップして処理されます。

RequestのインターフェイスにがasStringと宣言されていると、はるかに簡単になります。これは、ライブラリの場合、すべてのインタフェースのメソッドがthrows Exceptionであると結論づけています。私は正しい？

Answer 1

インターフェイスは、実装と仕様の間のAPIです。 APIをオーサリングしている場合は、APIによって何かがスローされることを許可するかどうかを知ることができます。

• いくつかのRuntimeExceptionでチェック例外をラップした例外のこれらの種類を投げることは許容され別のインターフェイスを実装し、または
• ：私はこの二つのアクションのいずれかを取るだろう、と述べた

  とにかくそれを泡立たせてください。

例外は理由により例外的です。あなたのコードが明示的にそれを期待しない限り、明示的に許可しないでください。