alternative ai tentativi di cattura nidificati per fallback

Ho una situazione in cui sto provando a recuperare un oggetto. Se la ricerca non riesce, sono presenti diversi fallback, ciascuno dei quali potrebbe non riuscire. Quindi il codice è simile al seguente:

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);
        }
    }
}

Sembra terribilmente brutto. Odio restituire null, ma è meglio in questa situazione?

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;

Ci sono altre alternative?

L'utilizzo di blocchi nidificati try-catch è un anti-pattern? è correlato, ma le risposte ci sono sulla falsariga di "a volte, ma di solito è evitabile", senza dire quando o come evitarlo.

Il modo normale per eliminare l'annidamento è utilizzare le funzioni:

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);
    }
}

Se queste regole di fallback sono universali, potresti prendere in considerazione l'implementazione direttamente repositorynell'oggetto, dove potresti essere in grado di usare solo semplici ifistruzioni anziché un'eccezione.

Questo sarebbe davvero facile con qualcosa come una monade Opzione. Sfortunatamente, Java non ne ha. In Scala, userei il Trytipo per trovare la prima soluzione di successo.

Nella mia mentalità di programmazione funzionale, avevo creato un elenco di callback che rappresentavano le varie fonti possibili e li scorrevo fino a trovare il primo successo:

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;

Questo può essere consigliato solo se si dispone davvero di un numero elevato di fonti o se è necessario configurare le fonti in fase di esecuzione. Altrimenti, questa è un'astrazione inutile e trarrai maggiori profitti dal mantenere il tuo codice semplice e stupido e usare solo quei brutti tentativi annidati.

Se si prevede che molte di queste chiamate al repository verranno lanciate NotFoundException, è possibile utilizzare un wrapper attorno al repository per semplificare il codice. Non lo consiglierei per le normali operazioni, intendiamoci:

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...

}

Su suggerimento di @ amon, ecco una risposta più monadica. È una versione molto ridotta, in cui devi accettare alcune ipotesi:

• la funzione "unit" o "return" è il costruttore della classe

• l'operazione "bind" avviene al momento della compilazione, quindi è nascosta dall'invocazione

• le funzioni "azione" sono anche legate alla classe al momento della compilazione

• sebbene la classe sia generica e racchiuda qualsiasi classe arbitraria E, penso che in questo caso sia davvero eccessivo. Ma l'ho lasciato in questo modo come esempio di cosa potresti fare.

Con queste considerazioni, la monade si traduce in una classe wrapper fluente (anche se stai rinunciando a molta flessibilità che avresti in un linguaggio puramente funzionale):

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;
    }
}

(questo non verrà compilato ... alcuni dettagli vengono lasciati incompiuti per mantenere il campione piccolo)

E l'invocazione sarebbe simile a questa:

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());

Nota che hai la flessibilità di comporre le operazioni di "recupero" come preferisci. Si interromperà quando riceverà una risposta o un'eccezione diversa da quella non trovata.

L'ho fatto molto velocemente; non è del tutto giusto, ma si spera trasmetta l'idea

Un altro modo per strutturare una serie di condizioni come questa è portare una bandiera, oppure testare null (ancora meglio, usare Guava's Optional per determinare quando è presente una buona risposta) al fine di concatenare le condizioni.

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;

In questo modo, stai osservando lo stato dell'elemento e stai effettuando le chiamate giuste in base al suo stato, vale a dire fino a quando non hai ancora una risposta.

(Sono d'accordo con @amon, però. Consiglio di guardare un modello Monad, con un oggetto wrapper come class Repository<E>quello che ha membri E answer;e Exception error;. Ad ogni fase controlla se c'è un'eccezione e, in tal caso, salta ogni passaggio rimanente. Alla fine, ti rimane una risposta, l'assenza di una risposta o un'eccezione e puoi decidere cosa farne.)

In primo luogo, mi sembra che ci dovrebbe essere una funzione come repository.getMostSimilar(x)(dovresti scegliere un nome più appropriato) in quanto sembra esserci una logica che viene utilizzata per trovare l'elemento più vicino o più simile per un dato elemento.

Il repository può quindi implementare la logica come mostrato nel messaggio di Amons. Ciò significa che l'unico caso in cui deve essere generata un'eccezione è quando non è possibile trovare un singolo elemento.

Tuttavia, ciò è ovviamente possibile solo se le logiche per trovare l'elemento più vicino possono essere incapsulate nel repository. Se ciò non è possibile, fornire ulteriori informazioni su come (in base a quali criteri) è possibile scegliere l'elemento più vicino.