System-Wide Single Exception(RuntimeException) vs Checked Exception에 대한 논의

의견 추가하기↓ / SLiPP 최신의견↓ / 페북 최신의견↓
자바지기 2013-03-21 08:49

어제 slipp 1기에 대한 마지막 스터디가 있었다. 마지막 스터디는 주제는 Exception과 Logging에 대한 내용이었다. http://www.slipp.net/wiki/pages/viewpage.action?pageId=8880291 문서에서 확인할 수 있다. Logging도 중요한 부분이지만 Logging 이야기는 없었고, Exception 관련 내용만 중점적으로 이야기했다.

어제 Exception 사용과 관련해서 뜨거운 논쟁을 한 주제가 있었다. 아마도 많은 곳에서 한번쯤은 고민해 봤을 법한 내용이다.

첫번째 방법은 6 Tips to Improve Your Exception Handling (http://northconcepts.com/blog/2013/01/18/6-tips-to-improve-your-exception-handling/)) 글에서 제안하는 바와 같이 System-wide Exception Class를 하나만 사용하자는 제안이다. Exception의 유형은 Exception 내에 ErrorCode를 Enum으로 두어 처리하는 방식이다.(편의를 위해 1번 방식)

두번째 방법은 자바의 Checked Exception을 활용하는 방법이다. 아마도 일반적으로 많은 곳에서 사용하는 방법이리라 생각한다.(편의를 위해 2번 방식)

위 두 가지에서 가정하고 있는 부분은 개발자가 Exception을 사용해야 되는 시점을 알고 있다는 것이다. 그리고 IOException, DB Connection Exception과 같이 시스템적으로 발생하는 Exception은 RuntimeException으로 처리한다고 가정하고 있다. 즉, 그 이야기는 System-wide Exception Class에서 Enum에 ErrorCode가 하나 추가되는 것이 두번째 방법에서는 하나의 Checked Exception이 추가되는 것으로 생각하면 된다.

만약 위와 같은 두 가지 Exception 처리 방식이 있다면 어떤 방식을 사용하겠는가? 만약 특정 방식을 사용한다면 그 이유는 무엇인가?

어제 나온 이야기들을 간략하게 정리하면 다음과 같다.

  • 1번 방식으로 구현할 경우 문서화를 잘 하거나 긴밀한 협업이 필요하다. 개발자가 기능 하나를 Front End부터 Back End까지 만들면 적합할 듯하다.
  • 1번 방식의 경우 ErrorCode가 한 곳에 모여 있어 어떤 에러가 있는지 찾기 쉽다. 2번의 경우에는 생각보다 쉽지 않다.
  • 2번이 협업이 잘 안되서나 개발조직이 분리되어 있는 경우 유리하다.
  • 자바를 제외하고 Checked Exception을 가진 언어가 많지 않다. 자바에 Checked Exception이 있기 때문에 이런 고민을 하는 것이 아닌가? 그냥 Runtime Exception만 있다고 가정하고 1번 방식으로 개발하면 되지 않나?
  • Exception에 대해 이렇게까지 고민하지 않았다. 그냥 개발자 편의대로 개발하면 되지 않나?
  • 과거에는 단순히 error code 값만 전달했다. 그런데 Exception이 등장한 것은 필요에 의해서 생긴 것인데 그 필요성에 집중한다면 굳이 Checked Exception과 UnChecked Exception을 구분할 필요가 없지 않나?

이 이외에도 다양한 의견들이 많이 나왔는데 모두 정리하지 못하겠다. 프로그래밍에서 Exception 처리는 상당히 중요하다고 생각한다. 하지만 많은 고려를 하지 않는 것이 Exception인 듯하다. 자바에서 Exception 처리를 어떤 방식으로 접근하는 것이 좋을지에 대해서 이야기해봤으면 좋겠다.

0개의 의견 from FB

3개의 의견 from SLiPP

benghun 2013-03-21 14:25

저는 checked exception은 비즈니스의 표현에 집중하기 위해 씁니다.

try { 
    heart.sendTo(girl);
    return Response.success();
} catch (HeartAlreadyUsedException e1) {
    /    * 
     * 이미 쓴 하트ID로 재요청된 경우 
     */
     return Response.fail(e1.code(), "should be refresh");
} catch (HeartReceiverInvalidException e2) {
    /    *
     * 하트 수신자가 탈퇴한 경우
     */
    return Response.fail(e2.code(), "might be dropped out user");
} catch (Exception e3) {
    logger.error(e3, e3);
    return Response.error(e3.code(), "retry or get out of here");
}
newoverguy 2013-03-21 14:50

저는 이 부분에 대해서 실무에서는 큰 고민을 두지 않고 있습니다. 논하는 부분에 대해서는 긍정적으로 보는 편이구요~

모든 것이 그렇지만 wide single Exception으로 표현해야 할 부분이 있고 checked Exception으로 표현해야할 부분.. 그리고, unchecked Exception으로 표현해야 할 경우가 생기게 됩니다.

다만, checked Exception으로 충분히 표현해도 되는데 wide single Exception을 사용한 경우에 논의 과정이라는 것이 필요하다고 봅니다. 그렇다면, 언제 wide를... 언제 checked를 .. 그리고 unchecked는..??? 여기서 위에 범위주에 checked와 unchecked를 논하는 것이 아니기도 하고 두 용처는 이미 많은 guru들이 설명을 하고 있으니 그것을 레퍼런스 하면 될 것 같습니다.

그러면 주 논의 대상인 wide single과 checked 부분인데.. 두 경우에 대해서 method를 생성하고 이를 사용하는 입장에서 보면... * wide single은.. try { xxxxMethod(); } catch(wideSingleException e) { throw e; }

해당 내용을 jsp에서 심플하게 처리하는 경우..

{e.errorCode} is {e.description}
하는 요구사항이라면 catch절이 simple 해지는 장점이 있습니다.

다만, try { xxxxMethod(); } catch(wideSingleException e) { if(e.errorCode == Enum.errorCode1) { //다른 할당 또는 처리... } 추가적인 if or else if ...... .... } 위와 같은 경우라는 각각을 catch절로 표현하는 것과 별 차이가 없고 더 좋지 않다고 봅니다.

또한, codetype을 갖는 정도의 biz. exception같은 wide single을 카테고리별로 다수로 갖는 것도 긍정적으로 봅니다. 다만, 카테고리화 될지 않는 것과 type까지 되지 않는 것에 대해서 wide single을 적용한다는 것은 지나친 code표현이라고 생각합니다.

  • 자세히 제가 위 아티클을 분석하지 않았지만..
  • checked vs unchecked 를 본하는 것은 이미 성숙된 논의 레퍼런스가 있다.
  • wide single vs 순수 checked 다수의 exception 표현에 대한 논의 인 것인데 이는 카테고리화될 수 있는 경우인 경우는 wide single 타입도 긍정적이다.

이 정도 의견을 올려 봅니다.

의견 추가하기

연관태그

← 목록으로