1

(私の例ではlinkパラメーターから) 例外メッセージを生成する必要がありますか、それともコンストラクターがパラメーターを取る必要がありmessageますか?

class ReadFromNotConnectedInputException extends RuntimeException {

    private String link;

    public ReadFromNotConnectedInputException(final String link)
    {
        this.link = link;
    }

    public String getLink()
    {
        return link
    }

    public String getMessage()
    {
        return String.format("Cannot read from link \"%\", link not connected.", link);
    }
}
4

4 に答える 4

3

以下のように書きます。ただし、例外を作成する努力をする場合は、それをチェック済みの例外にします。

class ReadFromNotConnectedInputException extends RuntimeException {
    private final String link;

    public ReadFromNotConnectedInputException(final String link) {
        super("Cannot read from link \"" + link + "\", link not connected.");
        this.link = link;
    }

    public String getLink() {
        return link
    }
}

また

class ReadFailedLinkNotConnectedException extends Exception {
    public ReadFailedLinkNotConnectedException (final String link) {
        super(link);
    }
}
于 2013-01-14T13:39:53.890 に答える
1

を選択したためRuntimeException、これはローカルで (スローされた場所の近くで) 処理するつもりはなく、多くの異なる例外を処理するスタック内のより高いレベルで処理することを意味します。

そのコンテキストでは、例外固有のロジックは関与しません。エラー エントリをログ ファイルに書き込み、クリーンアップします。したがって、単純なプロパティは、別個の String プロパティ + 複雑な実装messageよりも法案に適合します。getMessage

于 2013-01-14T13:38:24.787 に答える
0

パラメータを受け入れmessageて、スーパー コンストラクタを呼び出す必要があります。

于 2013-01-14T13:35:01.817 に答える
0

IMO例外がAPIの一部である場合は、コンストラクターでメッセージパラメーターを取得してスーパーに渡す必要があります。

その主な利点は、さまざまなモジュールからメッセージの形式を変更できることです。固定形式を維持すると、すべてが同じ形式のままになります。

于 2013-01-14T13:37:24.927 に答える