Define errors out of existence

예외를 발생시키기 전에 이 예외가 꼭 필요한 것인지 다시 한 번 생각해보자. 반드시 예외를 발생시키는 것만이 예외 상황을 처리하는 유일한 방법이 아닐 수도 있다. 가장 좋은 방법은 무분별하게 예외를 발생시키는 것보다 발상의 전환을 통해 상황에 유연하게 대처하는 것이다.

take n elements from iterable.

보통의 프로그래밍 언어에는 배열 타입이 있고, 필연적으로 배열에서 n개의 요소를 가져오는 방법이 있다. 이 글을 읽는 사람 또한 자주 사용하는 언어가 있다면 머릿속에 대번에 떠오르는 함수가 있을 것이다. 그렇다면 그 함수에서 배열의 크기보다 많은 요소를 가져오려고 하면 어떤 동작을 하는지도 확인해보자. 예외를 발생시키는지 아니면 전체 배열을 반환하는지, 그리고 어떤 방식이 더 적절한지도 생각해보자.

APoSD 정신은 이 경우 후자의 방법, 그러니까 예외 없이 전체 배열을 반환시키는 것이 나은 설계라고 말한다. 예외 처리를 위해 들어가는 로직이 코드의 복잡도를 높이고 인터페이스를 사용하는 유저의 실수를 구조적으로 방어함으로써 에러 자체를 없앨 수 있는 방법이기 때문이다. 단적으로 Java에서 list.subList(0, 3)이 size < 3일 때 IndexOutOfBoundsException을 발생시키는 반면, Kotlin의 list.take(3)은 size < 3인 경우에도 최대 길이를 반환하게 구현되어있다.

개발 서적에서 위로를 받다

만약 나에게 이 문제에 대한 경험이 없었다면 관습에 대한 또 하나의 Tab vs Space 논쟁에 지나지 않았을지도 몰랐을 일이지만, 회사에서 비슷한 일을 겪고 난 후 책에서 이 내용을 만났을 때 나는 이렇게 생각하는 것이 이상한 것이 아니구나 하고 묘하게 위로를 받았다. 권위 있는 혹은 널리 사용되는 것이 반드시 옳은 것이 아님을 알고 내가 사용하는 도구에 대해 정확하게 이해하는 것이 중요하다는 것을 배웠다.