<Effective Kotlin> 감상

Roeniss Moon·2022년 7월 2일
0

독서

목록 보기
13/29

한줄평

절반까지는 공감가는 내용도 많고 아! 하는 부분들도 있었는데 뒷부분은 이펙티브 자바의 뒷부분만큼이나 재미없었다.

인상 깊었던 부분들

return Result class, not throw exception

item 5,7,8

C# 개발을 하는 다른 훌륭한 개발자의 말을 인용해보자면, "exception"은 그 함수가 무슨 예외를 가지고 있는지 알기 어렵게 한다.

# pseudo code

# 이 방식보다
public ResultDto<String> getId_v1() { 
	val id = idGenerator.makeId(); // 이 안에서 어떤 예외들이 발생할 수도 있고, 전부 GlobalExceptionHandler 로 deletegate 되어 적절한 응답코드와 메시지를 리턴한다.
    return ResultDto.success(id);
}

# 이 방식이 '명확'하다
public ResultDto<String> getId_v2() {
	try {
	    val id = idGenerator.makeId();
        return ResultDto.success(id);
    } catch (NotAuthorized as e){
    	return ResultDto.fail(STATUS_CODE.401)    	
    } catch (GeneratorBusy as e){
    	return ResultDto.fail(STATUS_CODE.503)
    } catch (Exception as e){
    	// unknown
    	return ResultDto.fail(STATUS_CODE.500)
    }
}

예상하건대 많은 스프링 베이스 개발자들이 위 방식을 사용하고 있을 것이다. 그러나 아래 방식이 input/output 측면을 한 메서드 안에서 볼 수 있다는 면에서 더 정확하고, 더 적절한 책임을 분배하였으며 (controller 의 역할에 정확하게 부합), 더 예상 가능하다.

즉, 모든 예외를 처리하는 별도의 ExceptionHandler 가 Bad Pattern 이라는 주장이다. 물론 item 5 에서는 그렇게 까지 얘기는 안하지만..

더 적으려고 했는데 뭐가 딱히 없네. 망한 독서인듯.

덧대는 말

이펙티브 자바 보다는 (단순히 언어가 달라서가 아니라 말하고자 하는 컨텐츠 측면에서) 확실히 유익했다고 생각하는데 그 이유가 이 책이 실제로 더 잘 쓰여져서 그런지, 아니면 사실 내용은 양쪽 별반 다를게 없는데 나름대로 뭔가 성장해서 그런지, 그걸 모르겠다.

profile
기능이 아니라 버그예요

0개의 댓글