lựa chọn thay thế cho các lần thử bắt lồng cho dự phòng

Tôi có một tình huống mà tôi đang cố gắng để lấy một đối tượng. Nếu việc tra cứu thất bại tôi có một vài dự phòng, mỗi trong số đó có thể thất bại. Vì vậy, mã trông như:

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

Điều này trông cực kỳ xấu xí. Tôi ghét trả về null, nhưng điều đó có tốt hơn trong tình huống này không?

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;

Có những lựa chọn thay thế khác?

Là sử dụng các khối thử bắt lồng nhau là một mô hình chống? có liên quan, nhưng câu trả lời có hai dòng "đôi khi, nhưng thường là có thể tránh được", mà không nói khi nào hoặc làm thế nào để tránh nó.

Cách thông thường để loại bỏ lồng là sử dụng các hàm:

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

Nếu các quy tắc dự phòng này là phổ biến, bạn có thể xem xét thực hiện điều này trực tiếp trong repositoryđối tượng, nơi bạn có thể chỉ cần sử dụng các ifcâu lệnh đơn giản thay vì một ngoại lệ.

Điều này sẽ thực sự dễ dàng với một cái gì đó giống như một đơn vị Tùy chọn. Thật không may, Java không có những thứ đó. Trong Scala, tôi sẽ sử dụng Tryloại để tìm giải pháp thành công đầu tiên.

Trong tư duy lập trình chức năng của mình, tôi đã thiết lập một danh sách các cuộc gọi lại đại diện cho các nguồn có thể khác nhau và lặp qua chúng cho đến khi chúng tôi tìm thấy cuộc gọi thành công đầu tiên:

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;

Điều này chỉ có thể được đề xuất nếu bạn thực sự có số lượng nguồn lớn hoặc nếu bạn phải định cấu hình các nguồn khi chạy. Mặt khác, đây là một sự trừu tượng không cần thiết và bạn sẽ kiếm được nhiều tiền hơn từ việc giữ cho mã của bạn đơn giản và ngu ngốc, và chỉ sử dụng những lần thử xấu xí lồng nhau.

Nếu bạn dự đoán rằng sẽ có rất nhiều cuộc gọi kho lưu trữ sẽ được thực hiện NotFoundException, bạn có thể sử dụng trình bao bọc xung quanh kho lưu trữ để hợp lý hóa mã. Tôi sẽ không đề nghị điều này cho các hoạt động bình thường, nhớ bạn:

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

}

Theo đề nghị của @ amon, đây là một câu trả lời đơn điệu hơn. Đây là một phiên bản rất sôi nổi, nơi bạn phải chấp nhận một vài giả định:

• hàm "unit" hoặc "return" là hàm tạo của lớp

• hoạt động "liên kết" xảy ra vào thời gian biên dịch, vì vậy nó bị ẩn khỏi lệnh gọi

• các hàm "hành động" cũng được liên kết với lớp trong thời gian biên dịch

• mặc dù lớp này là chung chung và bao bọc bất kỳ lớp E tùy ý, tôi nghĩ rằng điều đó thực sự quá mức trong trường hợp này. Nhưng tôi đã để nó theo cách đó như một ví dụ về những gì bạn có thể làm.

Với những cân nhắc đó, đơn nguyên chuyển thành một lớp bao bọc trôi chảy (mặc dù bạn đang từ bỏ rất nhiều sự linh hoạt mà bạn có được bằng một ngôn ngữ hoàn toàn có chức năng):

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

(điều này sẽ không được biên dịch ... một số chi tiết nhất định còn dang dở để giữ cho mẫu nhỏ)

Và lời cầu khẩn sẽ như thế này:

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

Lưu ý rằng bạn có thể linh hoạt soạn các thao tác "tìm nạp" theo ý muốn. Nó sẽ dừng lại khi nhận được câu trả lời hoặc một ngoại lệ khác ngoài không tìm thấy.

Tôi đã làm điều này thực sự nhanh chóng; nó không hoàn toàn đúng, nhưng hy vọng truyền đạt ý tưởng

Một cách khác để cấu trúc một loạt các điều kiện như thế này là mang cờ hoặc kiểm tra khác bằng null (tốt hơn hết, sử dụng Tùy chọn của Guava để xác định khi nào có câu trả lời hay) để xâu chuỗi các điều kiện lại với nhau.

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;

Theo cách đó, bạn đang xem trạng thái của phần tử và thực hiện các cuộc gọi đúng dựa trên trạng thái của nó - nghĩa là, miễn là bạn chưa có câu trả lời.

(Tuy nhiên, tôi đồng ý với @amon. Tôi khuyên bạn nên xem mẫu Monad, với một đối tượng trình bao bọc class Repository<E>có thành viên E answer;và Exception error;. Ở mỗi giai đoạn, hãy kiểm tra xem có ngoại lệ nào không và nếu có, hãy bỏ qua từng bước còn lại. cuối cùng, bạn còn lại một câu trả lời, không có câu trả lời hoặc ngoại lệ & bạn có thể quyết định phải làm gì với điều đó.)

Đầu tiên, có vẻ như tôi nên có một hàm như repository.getMostSimilar(x)(bạn nên chọn một tên thích hợp hơn) vì dường như có một logic được sử dụng để tìm phần tử gần nhất hoặc tương tự nhất cho một phần tử nhất định.

Các kho lưu trữ sau đó có thể thực hiện logic như thể hiện trong bài amons. Điều đó có nghĩa là, trường hợp duy nhất một ngoại lệ phải được ném là khi không có yếu tố duy nhất có thể được tìm thấy.

Tuy nhiên điều này là tất nhiên chỉ có thể nếu logic để tìm phần tử gần nhất có thể được gói gọn vào kho lưu trữ. Nếu điều này là không thể, vui lòng cung cấp thêm thông tin về cách (theo tiêu chí nào) yếu tố gần nhất có thể được chọn.