Java에서 null 검사없이 값을 가져 오는 중

오류가 발생하기 쉽고 많은 상용구가 필요한 NullPointerExceptions을 피하기 위해 일부 데이터 계층에서 값을 가져올 때 null 검사를하는 경우가 많습니다.

객체를 가져올 때 null 검사를 건너 뛸 수있는 매우 간단한 루틴을 작성했습니다 ...

public final class NoNPE {

    public static <T> T get(NoNPEInterface<T> in) {
        try {
            return in.get();
        } catch (NullPointerException e) {
            return null;
        }
    }

    public interface NoNPEInterface<T> {
        T get();
    }
}

나는 이것을 조금 사용합니다 ...

Room room = NoNPE.get(() -> country.getTown().getHouses().get(0).getLivingRoom());

위의 결과로 모든 부모 수준을 null로 확인하지 않고도 Room 객체 또는 null을 얻을 수 있습니다.

위의 생각은 무엇입니까? 문제가있는 패턴을 만들고 있습니까? 귀하의 의견으로는 더 좋은 방법이 있습니까?

귀하의 솔루션은 매우 영리합니다. 내가 보는 문제는 왜 당신이 왜 당신이 모르는 사실 null입니까? 집에 방이 없었기 때문입니까? 마을에 집이 없었기 때문에? 나라에 마을이 없었기 때문입니까? 가 있었기 때문에이 되었습니까 null위치 (1) 더 큰 주택이있는 경우에도 오류로 인해 컬렉션의 0 위치를?

NonPE클래스를 광범위하게 사용 하면 심각한 디버깅 문제가 발생합니다. null더 깊은 오류를 숨길 수있는 체인을 자동으로 얻는 것보다 정확히 체인이 어디에서 깨 졌는지 아는 것이 낫다고 생각합니다 .

또한이는 위반 데메테르의 법칙 : country.getTown().getHouses().get(0).getLivingRoom(). 종종 좋은 원칙을 위반하면 그러한 원칙을 위반하여 발생하는 문제를 해결하기 위해 정통 솔루션을 구현해야합니다.

내 권장 사항은주의해서 사용하고 열차 잔해 반 패턴 에 발생하게하는 디자인 결함을 해결하려고 시도하는 것입니다 (따라서 NonPE어디에서나 사용할 필요는 없습니다 ). 그렇지 않으면 감지하기 어려운 버그가있을 수 있습니다.

아이디어는 훌륭하지만 실제로는 좋습니다. Java 8 Optional유형이 존재하므로 자세한 설명은 Java Optional type 에서 찾을 수 있습니다 . 게시 한 내용의 예는 다음과 같습니다.

Optional.ofNullable(country)
    .map(Country::getTown)
    .map(Town::Houses);

그리고 더.

디자인이 나쁜 것처럼 들리면 nulls를 반환하지만 메서드는 의도 한 목적에 맞게 충분히 작동합니다 NullPointerException.

null당신이 할 수있을 때 s를 피하고 무언가를 나타내거나 특별한 의미가있을 때만 전달하고 무언가를 나타내거나 의미 할 때만 반환하십시오 NullPointerException. 그렇지 않으면을 던져야합니다 . 이것은 버그와 혼란을 피합니다. 이 경우 Object안 null, a는 NullPointer발생한다. 객체 null가 전달 될 수 있으면 객체 가 전달 될 때 아무 것도 잘못되지 않습니다. 그렇지 않으면 위의 방법이 작동합니다.

나는 당신의 고통을 느낄 수 있지만 제안 된 해결책은 나쁜 생각입니다.

• 게터 중 하나가 다른 이유로 NPE를 던지면 무시합니다.
• 그 내부 람다가 끔찍한 코드로 자랄 위험이 있습니다. 예를 들어, 마을에 집이 없을 때 특수 상수를 반환해야하는 새로운 요구 사항이있는 경우 게으른 프로그래머는 모든 것을 래핑하여 lamda를 확장 할 수 있습니다 NoNPE.get.
• 이미 언급했듯이, Optional.map당신이 찾고있는 것입니다.
• NullPointerException의 새 인스턴스를 작성하는 데 따르는 처벌은 종종 중요합니다. 특히 통화 스택이 커짐에 따라 수 마이크로 초입니다. 유틸리티가 어디에서 사용되는지 예측하기는 어렵습니다.

부수적 NoNPEInterface으로의 복제본입니다 java.util.function.Supplier.

경우에 따라 많은 프레임 워크 (예 : EL, SpEL)에있는 표현식 평가 유틸리티 사용을 고려할 수 있습니다.

evaluateProperty(country, "town.houses[0].livingRoom")