return null 은 좋지 않다?
작업을 하다가 return null 으로 리터럴 타입을 지정하는 경우가 종종 있다.
본인도 어느정도 코드 규약에서 해당 경우를 사용해서 궁금증이 생겨서 좀더 찾아보게 되었다.
null 리턴은 왜 나쁠까? [원문]
해당 글을 보게되면서 간략하게 개인 생각을 정리하는 포스팅을 한다.
반응형
< return null 사용하면 안되는 간략한 이유 >
단점 | 설명 |
잠재적인 null 참조 예외 | 호출 코드가 반환된 값을 적절하게 처리하지 않고 해당 값이 null이 아니라고 가정하는 경우 런타임에서 Null 참조 예외가 발생할 수 있습니다. |
명확성 부족 | null을 반환하면 의도한 작업을 수행할 수 없는 이유를 명확하게 전달되지 못한다. 유효한 결과가 아닌지 문제의 징후인지 불분명할 수 있다. |
오류 발생 가능성 | 개발자가 반환 값을 사용할 때 null 확인을 잊어버려 추적 및 수정의 어려운 버그가 발생 할 수 있다. |
대체 접근 방식 | 상황에 따라 메서드가 실패한 이유가 보다 정확한 정보를 제공하고 실패 시 명시적으로 처리하도록 하는 예외 발생 또는 null 허용 유형 사용과 같이 더 다른 대안이 있는 경우도 있다. |
이유를 알아봤으면 이제 다른 return null 을 대안할 대체 접근 방식을 알아보자.
< 1 - Nullable 값 사용 >
public class NullableExample
{
public int? GetNullableValue(bool condition)
{
return condition ? 42 : (int?)null;
}
}
< 2 - 예외 발생 >
public class ExceptionExample
{
public int Divide(int numerator, int denominator)
{
if (denominator == 0)
throw new ArgumentException("Denominator cannot be zero.");
return numerator / denominator;
}
}
< 3 - 정의된 기본값을 사용 >
정의된 기본값 ( -1) 혹은 string.Empty 같은 형식으로 사용
< 4 - 결과를 포함하는 클래스 구조로 반환 >
public class ClassResult<T>
{
public bool Success { get; set; }
public T Result { get; set; }
}
public class SimpleClassResultExample
{
public ClassResult<int> Divide(int numerator, int denominator)
{
if (denominator == 0)
{
return new ClassResult<int> { Success = false, Result = -1 };
}
return new ClassResult<int> { Success = true, Result = numerator / denominator };
}
}
※ 상황에 따라 다르다는 것을 꼭 명심해서 사용해야한다.
★★★☆☆
반응형
'개발 > 개인적인 생각' 카테고리의 다른 글
읽을거리)소프트웨어 개발자의 생산성을 측정하는 방법 (0) | 2024.01.30 |
---|---|
개인생각) 개발팀의 행복을 유지하는 요소 (0) | 2023.12.29 |
개인생각) 물 경력에 대한 고민 (0) | 2023.08.24 |
개인생각) MZ 세대와 효과적으로 협업 하는 방법 (0) | 2023.07.02 |
개인생각) 개발(UI/UX)에서 공백(여백)에 대한 생각 (0) | 2023.06.15 |
댓글