フォールバック用のネストされたトライキャッチの代替

オブジェクトを取得しようとしている状況があります。ルックアップが失敗した場合、フォールバックがいくつかあり、それぞれが失敗する可能性があります。したがって、コードは次のようになります。

try {
    return repository.getElement(x);
} catch (NotFoundException e) {
    try {
        return repository.getSimilarElement(x);
    } catch (NotFoundException e1) {
        try {
            return repository.getParentElement(x);
        } catch (NotFoundException e2) {
            //can't recover
            throw new IllegalArgumentException(e);
        }
    }
}

これはひどくいです。nullを返すのは嫌いですが、このような状況ではより良いですか？

Element e = return repository.getElement(x);
if (e == null) {
    e = repository.getSimilarElement(x);
}
if (e == null) {
    e = repository.getParentElement(x);
}
if (e == null) {
    throw new IllegalArgumentException();
}
return e;

他の選択肢はありますか？

ネストされたtry-catchブロックの使用はアンチパターンですか？関連しているが、そこにある答えは「いつか、しかし通常は避けることができる」という線に沿っており、いつ、どのようにそれを避けるべきかは述べていない。

ネストを排除する通常の方法は、関数を使用することです：

Element getElement(x) {
    try {
        return repository.getElement(x);
    } catch (NotFoundException e) {
        return fallbackToSimilar(x);
    }  
}

Element fallbackToSimilar(x) {
    try {
        return repository.getSimilarElement(x);
     } catch (NotFoundException e1) {
        return fallbackToParent(x);
     }
}

Element fallbackToParent(x) {
    try {
        return repository.getParentElement(x);
    } catch (NotFoundException e2) {
        throw new IllegalArgumentException(e);
    }
}

これらのフォールバックルールが普遍的である場合は、これをrepositoryオブジェクトに直接実装することを検討してくださいif。例外の代わりに単純なステートメントを使用できる場合があります。

Optionモナドのようなものを使えば、これは本当に簡単です。残念ながら、Javaにはそれらがありません。Scalaでは、このTryタイプを使用して最初の成功したソリューションを見つけます。

私の機能プログラミングの考え方では、考えられるさまざまなソースを表すコールバックのリストを設定し、最初に成功したソースが見つかるまでループします。

interface ElementSource {
    public Element get();
}

...

final repository = ...;

// this could be simplified a lot using Java 8's lambdas
List<ElementSource> sources = Arrays.asList(
    new ElementSource() {
        @Override
        public Element get() { return repository.getElement(); }
    },
    new ElementSource() {
        @Override
        public Element get() { return repository.getSimilarElement(); }
    },
    new ElementSource() {
        @Override
        public Element get() { return repository.getParentElement(); }
    }
);

Throwable exception = new NoSuchElementException("no sources set up");
for (ElementSource source : sources) {
    try {
        return source.get();
    } catch (NotFoundException e) {
        exception = e;
    }
}
// we end up here if we didn't already return
// so throw the last exception
throw exception;

これは、実際に多数のソースがある場合、または実行時にソースを構成する必要がある場合にのみ推奨できます。それ以外の場合、これは不必要な抽象化であり、コードをシンプルかつ愚かに保ち、それらのいネストされたtry-catchを使用することでより多くの利益を得られます。

これらのリポジトリー呼び出しの多くがスローされると予想している場合NotFoundException、リポジトリーのラッパーを使用してコードを合理化できます。通常の操作にはこれをお勧めしません。

public class TolerantRepository implements SomeKindOfRepositoryInterfaceHopefully {

    private Repository repo;

    public TolerantRepository( Repository r ) {
        this.repo = r;
    }

    public SomeType getElement( SomeType x ) {
        try {
            return this.repo.getElement(x);
        }
        catch (NotFoundException e) {
            /* For example */
            return null;
        }
    }

    // and the same for other methods...

}

@amonの提案では、もっとモナド的な答えがあります。これは非常に要約されたバージョンであり、いくつかの前提を受け入れる必要があります。

• 「ユニット」または「リターン」関数はクラスコンストラクターです

• 「バインド」操作はコンパイル時に発生するため、呼び出しから隠されます

• 「アクション」関数もコンパイル時にクラスにバインドされます

• クラスはジェネリックであり、任意のクラスEをラップしますが、実際にはこの場合はやり過ぎだと思います。しかし、私はあなたができることの例としてそれを残しました。

これらの考慮事項により、モナドは流なラッパークラスに変換されます（ただし、純粋に関数型言語で得られる柔軟性の多くを放棄しています）。

public class RepositoryLookup<E> {
    private String source;
    private E answer;
    private Exception exception;

    public RepositoryLookup<E>(String source) {
        this.source = source;
    }

    public RepositoryLookup<E> fetchElement() {
        if (answer != null) return this;
        if (! exception instanceOf NotFoundException) return this;

        try {
            answer = lookup(source);
        }
        catch (Exception e) {
            exception = e;
        }

        return this;
    }

    public RepositoryLookup<E> orFetchSimilarElement() {
        if (answer != null) return this; 
        if (! exception instanceOf NotFoundException) return this;

        try {
            answer = lookupVariation(source);
        }
        catch (Exception e) {
            exception = e;
        }

        return this;
    }

    public RepositoryLookup<E> orFetchParentElement() {
        if (answer != null) return this; 
        if (! exception instanceOf NotFoundException) return this;

        try {
            answer = lookupParent(source);
        }
        catch (Exception e) {
            exception = e;
        }

        return this;
    }

    public boolean failed() {
        return exception != null;
    }

    public Exception getException() {
        return exception;
    }

    public E getAnswer() {
        // better to check failed() explicitly ;)
        if (this.exception != null) {
            throw new IllegalArgumentException(exception);
        }
        // TODO: add a null check here?
        return answer;
    }
}

（これはコンパイルされません...サンプルを小さく保つために特定の詳細は未完成のままです）

そして、呼び出しは次のようになります。

Repository<String> repository = new Repository<String>(x);
repository.fetchElement().orFetchParentElement().orFetchSimilarElement();

if (repository.failed()) {
    throw new IllegalArgumentException(repository.getException());
}

System.err.println("Got " + repository.getAnswer());

必要に応じて「フェッチ」操作を柔軟に構成できることに注意してください。見つからない以外の回答または例外を取得すると停止します。

私はこれを本当に速くしました。それはまったく正しくありませんが、うまくいけばアイデアを伝えます

このような一連の条件を構成する別の方法は、フラグを保持するか、条件を連結するためにnullをテストすることです（さらに良いのは、Guava's Optionalを使用して適切な回答が存在するかどうかを判断することです）。

Element e = null;

try {
    e = repository.getElement(x);
} catch (NotFoundException e) {
    // nope -- try again!
}

if (e == null) {  // or ! optionalElement.isPresent()
    try {
        return repository.getSimilarElement(x);
    } catch (NotFoundException e1) {
        // nope -- try again!
    }
}

if (e == null) {  // or ! optionalElement.isPresent()
    try {
        return repository.getParentElement(x);
    } catch (NotFoundException e2) {
        // nope -- try again!
    }
}

if (e == null) {  // or ! optionalElement.isPresent()
    //can't recover
    throw new IllegalArgumentException(e);
}

return e;

そのようにして、要素の状態を監視し、その状態に基づいて適切な呼び出しを行います。つまり、まだ答えが得られていない限りです。

（ただし、@ amonに同意します。Monadパターンを見て、class Repository<E>メンバーE answer;とを持つラッパーオブジェクトを使用することをお勧めしますException error;。各段階で例外があるかどうかを確認し、そうであれば、残りの各ステップをスキップします。最後に、答え、答えの欠如、または例外のいずれかが残ります。それをどうするかを決定できます。

まず、repository.getMostSimilar(x)特定の要素に最も近いまたは最も類似した要素を見つけるために使用されるロジックがあるように見えるため、（より適切な名前を選択する必要があります）のような関数があるはずです。

その後、リポジトリはamonsポストに示されているようなロジックを実装できます。つまり、例外をスローする必要があるのは、検出できる要素が1つもない場合だけです。

ただし、これはもちろん、最も近い要素を見つけるロジックをリポジトリにカプセル化できる場合にのみ可能です。これが不可能な場合は、最も近い要素をどのように（どの基準で）選択できるかについて、より多くの情報を提供してください。