Kotlin과 Java는 예외를 기본 오류 처리 메커니즘으로 사용합니다. 이는 Rust처럼 Result 타입을 중심으로 설계된 언어와는 다른 접근 방식입니다.
그럼에도 Kotlin에서 Result를 사용하는 이유는 해당 작업이 실패할 수 있다는 것을 명시적으로 표현하기 때문입니다.
대부분의 웹 프레임워크는 전역 예외 핸들러(Global Exception Handler) 기능을 제공합니다. 따라서 개발자는 프레임워크 내부의 비즈니스 로직 작성에만 집중할 수 있습니다.
"명시적으로 실패를 알려주어 필요에 따라 복구하도록 의도하는 경우" 에 Result를 사용합니다. 이를 통해 코드 차원에서 실패 가능성을 명시적으로 표현할 수 있습니다.
복구 불가능한 에러의 경우 굳이 Result로 감쌀 필요가 없습니다. 실패 가능성을 알아도 복구할 수 없다면, Result로 감싸는 것은 단순히 wrap/unwrap 코드만 늘어나게하고, 인지 부하를 늘릴 뿐임.
어치피 전역 예외 핸들러가 예외를 잡아주므로, 그런 예외는 숨기는게 나음. (적어도 오류 처리를 예외로 하는 언어에선)
- 비즈니스 로직 상의 검증 실패 중 처리 가능한 경우
- 사용자 입력 오류
- 권한 부족 등 대안적 처리가 가능한 경우
(위 에러 대부분도 일반적인 경우라 프레임워크에서 전역 예외 핸들러가 처리 가능하게 되어있음. 그래서 실제론 Result로 복구가 필요한 사례가 거의 없음.)
- API 호출 시 네트워크 에러
- 데이터베이스 에러 (이미 트랜잭션이 실패하여 새로 실행해야 하는 경우)
- 시스템 리소스 부족
주의: 위 분류는 예시이며, 실제 상황과 요구사항에 따라 달라질 수 있습니다.
복잡하고 절차적인 함수에서 예외 발생할 수 있는 함수를 호출하지만 에러가 발생해도, 복구해서 다음 작업을 무조건 실행해야 하는 경우.
try-catch를 사용하면 어디서 에러가 나서 빠질 지 모르니까 코드가 복잡해짐.