지난 주에 Kenny가 전하는 뜬금없는 정보 공유 4번째(http://www.slipp.net/questions/71)에도에도) 있었지만 Exception Handling은 참 쉽지 않다는 생각을 종종 합니다. A라는 방식으로 구현하면 이런 이슈가 있고, B라는 방식으로 구현하면 저런 이슈가 발생하는 경우가 많더군요.

Kenny가 전한 http://northconcepts.com/blog/2013/01/18/6-tips-to-improve-your-exception-handling/ 문서를 보면 Exception Handling을 향상하기 위한 6가지 팁을 제공하고 있는데요. 같이 함 보자.

• Use a single, system-wide exception class
• Use enums for error codes
• Add error numbers to enums
• Add dynamic fields to your exceptions
• Prevent unnecessary nesting
• Use a central logger with a web dashboard

이 문서에서 제시하는 소스 코드까지 확인해 보면 나름 괜찮은 방법이라는 생각이 든다. 아직까지 Exception Handling에 대한 명확한 기준 없이 프로젝트에 따라 다르게 사용해 왔는데 나름 유용한 방법이라 생각한다.

위 문서에서 제시한 방법 외에 Exception Handling에 대한 괜찮은 방법이 있을까요? 위 방식이 가지는 문제점은 뭘까요?

위 방식에 이슈를 제기한다면 system-wide exception을 Runtime Exception으로 만듦으로써 API에서 어떤 Exception이 발생하는지 소스 코드나 문서를 확인하기 전까지는 확인할 방법이 없다. 또한 Exception이 발생하는 것을 안다고 하더라도 어떤 Exception이 발생하는지 알기 어렵다. 위 방식이 간편해 정말 유용할 것으로 생각한다. 하지만 위 방식은 개발자간의 협업이 긴밀한 경우에는 정말 유용하리라 생각되지만 그렇지 않은 경우에는 문서화나 다른 방식으로 이슈를 해결할 수 밖에 없지 않을까 생각된다. 그렇다면 각각의 Exception 상황에 따라 Exception Class를 만드는 것도 여간 짜증나는 작업이 아니다. 클래스 수도 많아지고, Exception Handling에 대한 명확한 가이드가 없으면 개발자에 따라 중구 난방으로 개발하는 경우도 많이 보았기 때문이다.

그럼 각 상황에 맞게 2,3가지 유형으로 개발하도록 해야 하나? 그것도 썩 좋은 방법은 아니라는 생각이 든다. 암튼 쉬운 듯하지만 쉽지 않은 것이 Exception Handling 부분이다.