JAVA의 예외 처리와 소스 코드 길이 차이

1. 불편한 예외처리

다른 객체지향 언어들처럼, 자바 역시 try~catch문으로 대표되는 예외 처리를 할 수 있습니다. 대부분의 언어에서 차용하고 있는 좋은 기능이지만, 유독 자바는 다른 언어와는 달리 프로그래머의 검사가 필요한 예외(Exception을 직접 상속하는 예외 클래스)가 등장한다면 무조건 프로그래머가 선언을 해줘야 합니다. 그렇지 않으면 컴파일조차 거부합니다. 원래 의도는 '철저한 예외 처리를 하니까 만약에 발생할 수 있는 모든 상황에 안정성을 확보할 수 있겠지.'였으나, 결국 대부분의 경우엔 귀찮다는 이유로, 가장 일반적인 예외인 Exception, 더 막 나가면 Throwable 하나만 써서 넘어가버리고 폭탄 돌리듯 넘기기만 하거나(예외 던지기만 하고 try~catch 안 하면 메서드를 돌고 돌다가 콰광!), 예외 나든 말든 무시해 버리는 경우가 가장 흔합니다. 이런 코드가 너무 흔해 빠진 나머지 이딴 식으로 쓸 거면 왜 넣었냐고 까는 사람도 많았습니다. 그런데 선언이 필요 없는, 검사 안 하는 예외도 자바에 많고, C++이나 C# 같이 예외가 있는 언어라도 자바처럼 예외를 쓰는 경우는 별로 없습니다. 두 언어는 모든 예외가 검사 안 하는 예외입니다. 사실 예외 처리를 한다는 것은 귀차니즘과 견고함을 맞바꾸는 일인데, 안 할 사람은 문법으로 강제해도 안 한다는 것을 보여준 것입니다.

 

대부분의 다른 언어에서는 원하는 에러만 try-catch문으로 뽑아내고 그렇지 않은 경우에는 그냥 아무 처리를 해주지 않아도 됩니다. 이러한 언어를 접하던 사람이 자바를 접하면 그 특유의 경직된 예외처리에 불편해하기도 합니다. 오히려 명시적으로 예외처리를 할 수 없는 경우도 존재하는데, 인터페이스를 상속받을 때 인터페이스에 선언된 예외가 아니면 구현 클래스에서 그 예외를 던질 수 없습니다. 특히, 자바에서 제공하는 Iterator 인터페이스에는 throws 선언 따위는 없기 때문에 Iterator를 구현받았을 때 명시적으로 예외를 던질 수 없습니다. 이 상황을 해결하려면 RuntimeException 계열을 쓸 수밖에 없는 상황이 펼쳐집니다.

 

다만, 상기의 내용은 실무적 접근에 의한 내용이고, 실제로는 이는 장점으로도 취급되기도 합니다. Assert문을 자유자재로 쓰면서 예외처리를 하거나 코딩과 동시에 발생할 수 있는 각종 예외들을 인지하고 처리해주는 걸 잊어먹는 경우에 대한 대처가 가능하기때문입니다.

 

2. JAVA의 소스 코드 길이

자바는 소스 코드의 길이가 다른 언어에 비해 상당히 긴 편입니다. 같은 기능을 하는 코드를 짠다고 했을 때 다른 언어에 비해 타이핑해야 할 양이 많습니다. 구체적으로 말하자면 일명 Boilerplate라고 부르는, 기본적인 구조를 짜기 위해서 무조건 의무적으로 작성해 주어야만 하는 서식과 코드의 분량이 많습니다.

 

인터프리터 언어에서는 puts("Hello") 정도로 끝났을 일을 자바에서는

class Main {
    public static void main(String args[]) {
        System.out.println("Hello");
    }
}

이만큼을 써야 합니다. 같은 일을 하는 C언어 코드는

#include<stdio.h>

int main() { 
    puts("Hello");
}

파이썬의 경우는

print("Hello")

위키 책에 있는 Hello World 프로그램의 목록이나, 나무 위키 내의 프로그래밍 언어/예제 문서를 보면 하이레벨 언어 중에서는 코드량이 긴 편인 걸 알 수 있습니다.

 

오죽하면 이런 포스트가 만들어질까요? 물론 이건 자바의 문제가 아니고 마세라티 문제라고 알려진 프로그래머의 과욕이 부른 참상이지만 코드에 유연성을 조금 추가하기 위해 써넣어야 할 코드의 길이가 기하급수로 증가한다는 하나의 예시로 볼 수 있습니다. 참고로 저 포스트의 5년 차 코드는 Spring의 패러디입니다. Java 이후에 나온 차세대 언어들은 같은 수준의 유연성을 확보하기 위해 들여야 할 노력의 양이 훨씬 적습니다.

 

이렇게 의도적인 장황함(verbosity)을 추구하는 언어 설계와 커뮤니티의 문화가 아이러니하게도 위에서 언급한 장점이 무색하게 가독성을 저해하는 요인이 되기도 합니다. 같은 기능을 하더라도 수십 줄의 보일러 플레이트 코드를 가지는 자바 코드보다 다른 언어의 코드가 보통은 더 읽기 쉽기 때문이죠.

 

게다가 다른 하이레벨 언어(C#, Python, Ruby 등)에 비해 문법적 설탕(Syntactic sugar)이 적어 이쪽에서 넘어오면 꽤 불편해하는 편입니다. 하지만 최근 Java 8로 넘어오면서 람다 표현식, 스트림 등을 지원하는 식으로 문법적 편리함을 늘려가는 추세입니다. 이 흐름은 다음 Java 9에서 더욱 강화될 것으로 보는 추세입니다.

 

그러나 무조건 타이핑의 양이 많다고 해서 나쁜 것만 있는 것이 아닙니다. 일단 자바는 명색이 클래스 지향적이기 때문에 어쩔 수 없는 부분이고, 커다란 프로젝트 단위에서 봤을 땐 오히려 클래스와 메서드, 변수의 소속이 확실하기 때문에 코드를 금방 파악할 수 있습니다. 축약어의 사용을 최대한 자제하는 방향으로 만들었기 때문에 그렇습니다. Python이나 JavaScript 같은 동적 타입 언어들은 소규모 프로젝트에는 좋겠지만 대형 프로젝트에서는 불편할 수도 있습니다.

 

JetBrains에서 개발한 Kotlin은 바로 이 Java의 언어적 불편함을 최소화하려고 나온 새 프로그래밍 언어이며, 카카오에서도 카카오톡 메시징 서버에 Kotlin을 도입하는 등(#) Java를 Kotlin으로 대체하려는 움직임이 조금씩 나타나고 있습니다.