삭제하도록 지정된 항목이 없으면 서비스에서 예외가 발생하거나 반환되어야 함

다음과 같이 나타낼 수있는 코드가 있습니다.

public class ItemService {

    public void DeleteItems(IEnumerable<Item> items)
    {
        // Save us from possible NullReferenceException below.
        if(items == null)
            return;

        foreach(var item in items)
        {
            // For the purpose of this example, lets say I have to iterate over them.
            // Go to database and delete them.
        }
    }
}

이제 이것이 올바른 접근법인지 또는 예외를 던져야하는지 궁금합니다. 반환은 빈 컬렉션을 반복하는 것과 동일하기 때문에 예외를 피할 수 있습니다. 즉, 중요한 코드는 실행되지 않지만 다른 한편으로는 코드의 어딘가에 문제가 숨어있을 수 있습니다. DeleteItems와 null매개 변수? 코드 어딘가에 문제가 있음을 나타낼 수 있습니다.

이것은 대부분 서비스에서 메소드와 관련하여 발생하는 문제입니다. 대부분이 무언가를하고 결과를 반환하지 않기 때문에 누군가가 잘못된 정보를 전달하면 서비스가 수행 할 작업이 없으므로 반환됩니다.

이들은 두 가지 다른 질문입니다.

수락해야합니까 null? 그것은 null코드베이스 에 대한 일반적인 정책에 달려 있습니다 . 내 의견으로는, null명시 적으로 문서화 된 곳을 제외한 모든 곳 에서 금지 하는 것은 매우 좋은 습관이지만 코드베이스가 이미 가지고있는 규칙을 따르는 것이 더 좋습니다.

빈 컬렉션을 수락해야합니까? 제 생각에는 그렇습니다. 수학적으로 옳은 일을하는 것보다 모든 발신자를 비어 있지 않은 모음으로 제한하는 것이 훨씬 더 많은 노력입니다.

널값

@KilianFoth가 이미 말했듯이 일반적인 정책을 준수하십시오. null빈 목록의 "속기" 로 취급 하려면 그렇게하십시오.

null값 에 대한 일관된 정책이없는 경우 다음을 권장합니다.

null" null알 수 없음"을 나타내는 데 사용하는 등 "일반"유형으로 표현할 수없는 상황을 나타내도록 예약해야합니다 . 부주의하게이 값을 사용하려고하면 예외가 발생하므로 올바른 선택입니다.

null비어있는 목록의 속기로서 사용 하는 것은 이미 완벽한 표현이 있기 때문에 요소가없는 목록이기 때문에 그런 식으로 자격이 없습니다. 그리고 목록을 다루는 코드의 모든 부분이 유효한 속기를 검사하도록 강요하기 때문에 기술적으로 나쁜 선택 null입니다.

빈 목록

A의 DeleteItems()방법, 빈리스트를 건네 주면 효과적으로 아무것도하지 않는 것을 의미합니다. 나는 예외를 던지지 않고 단지 빨리 돌아 오는 것을 인수로 허용 할 것입니다.

물론, 호출자는 먼저 0 요소를 확인하고이 경우 DeleteItems()호출을 건너 뛸 수 있습니다. 우리가 웹 API에 대해 이야기하고 있다면, 효율성상의 이유로 호출자 는 실제로 불필요한 트래픽과 왕복 대기 시간을 피하기 위해 그렇게해야합니다. 그러나 나는 당신의 API가 그것을 강요해야한다고 생각하지 않습니다.

호출 코드에서 예외를 처리하고 널을 처리하십시오.

설계 규칙에 따라 매개 변수 값으로 null을 피하십시오. null은 실제로 예외이므로 일반적으로 NullPointerException을 줄입니다.

그 외에도 나머지 코드를 살펴보십시오. 이것이 프로젝트에서 일반적인 패턴 인 경우 일관성을 유지하십시오.

일반적으로 예외 상황이 발생하는 경우 (예 : 코드에 현재 상황에서 취할 적절한 조치가없는 경우) 예외 발생을 예약해야합니다.

이 사고 과정을이 상황에 적용 할 수 있습니다. 이것이 공개 메소드가있는 공개 클래스이므로 공개 API가 있으며 이론적으로 전달되는 내용을 제어 할 수 없습니다.

코드에는 호출 대상에 대한 컨텍스트가 없으며 null 값으로 합리적으로 수행 할 수있는 작업이 없습니다. 이것은 확실히 후보가 될 것 ArgumentNullException입니다.

이 질문은 예외에 관한 것이 아니라 null유효한 논증 에 관한 것 같습니다 .

따라서 무엇보다도 null해당 메소드의 인수에 허용되는 값 인지 여부를 결정 해야합니다. 그렇다면 예외가 필요하지 않습니다. 그렇지 않은 경우 예외가 필요합니다.

당신이 허용하든 원하지 않든간에 null많은 구글 히트에 의해 논란의 여지가 있습니다. 의미, 당신은 명확한 대답을 얻을 수 없습니다, 그것은 당신이 일하는 곳에서 의견과 전통에 다소 달려 있습니다.

또 다른 경합 영역은 라이브러리 함수가 잘못된 매개 변수를 "고정"하려고하지 않는 한 그러한 것들에 대해 실제로 엄격 해야하는지 아니면 가능한 한 관대 해야하는지 입니다. 이것을 네트워크 프로토콜, 메일 전송 등 (프로그래밍 방법과 같은 인터페이스 계약)의 세계와 비교하십시오. 일반적으로 정책은 발신자가 프로토콜을 최대한 엄격하게 준수해야하며 수신자는 어떤 상황에서도 작업 할 수 있도록해야합니다.

따라서 결정해야합니다. 실제로 null처리 와 같은 대규모 정책을 시행하는 것이 라이브러리 방법의 역할 입니까? 특히 도서관이 다른 사람들도 사용하는 경우 (다른 정책이있을 수 있음).

나는 null값 을 허용 하고, 의미를 정의하고 문서화하는 (즉, null = empty array이 경우) 측면에서 실수를 저지르고 다른 유사한 코드 ( "라이브러리"스타일 코드)의 99 %가 다른 방식으로 수행하지 않는 한 예외를 throw 하지 않을 것입니다 '일주.