return 설계

때때로 method 내에서 정상 로직 진행에 실패한 경우에도 data를 상위 메서드에 전달해야 하는 경우가 있다. (e.g., 추가인증필요, 기처리) 기본적으로 throw Exception을 return 처럼 data 반환 용도로 사용하는 것은 불가능 하기 때문에, return 기반으로 접근해야 한다. 직접 return 타입 정의해 사용하기 data class FooResult( val code: Code, val field1OnlyIfSuccess, val field2OnlyIfSuccess, val field3OnlyIfFailure } { enum Code { SUCCESS, FAILURE } } Result 타입 R 타입에 code 없고 성공+실패 data field만 존재하는 경우 유용. 보편적..

중요한 처리로직 인 경우, 어차피 caller는 callee를 믿어서는 안된다. 여기서 callee는 다른 class 혹은 다른 class의 메서드를 의미한다. 같은 class 내 private method를 호출하는 경우라면, 자기 자신이 직접 정의한 기능이므로 믿을 수 있으나, class 바깥의 다른 class와 메시지를 주고 받는 상황이라면 신뢰하지 않는 것을 기본 전제로 깔고가야 한다. 예시 ) 금액 소진 메서드를 제공하는 callee가 Exception을 반환하지 않겠다고 docstring에 명시해두었다면 믿을 것인가? 금액 소진 기능인데, callee의 docstring과 현재 구현된 메서드 내부만 믿고 caller는 catch 안할 것인가? 그럴리가 없다는 것이다. caller 입장에서 ca..

return 대신 throw Exception 하면서 유용한 객체를 함께 반환하는 것은 불가능하다. (가능은 하지만 타입 정보가 사라져서 정적 타입 언어를 제대로 사용하는 방법이 아니다.) return Type 개수 만큼 Exception class를 정의 할 수는 없으니 generic을 이용해 CommonException 같이 정의하고 data: T에 데이터 담아서 던지면 되는거 아닌가 생각이 들 수 있는데 runtime에는 T가 사라지기 때문에 type-safe한 catching이 불가능하다. ( link ) 애초에 subclass of 'throwable' may not have type parameters 로 컴파일타임 에러가 발생하기 때문에 CommonException을 Generic으로 만들 ..

예시 API 응답으로 수신하는 code 및 그에 따른 반환값 when (response.code) { 1000 -> 성공 (데이터 반환) 1007 -> 기처리 (데이터 반환) 2000 -> 구분해야하는 실패1 2001 -> 구분해야하는 실패2 else -> 그 외 모든 응답 코드(실패) } 예시 상황에서, External Client class에서 Exception을 직접 던지는게 나을까? 아니면 return 기반으로 가는게 나을까? 둘 다 사용하는 hybrid로 가는게 나을까? External Client class에서 Exception을 직접 던지는 경우 예시) 후술하겠지만 이렇게 처리하는 것은 좋지 않다. AbcClient { fun post() { val response = webClient.po..