<div id="readability-page-1" class="page"><div><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/0*9mIjyJhsQtI8T_tC" width="700" height="1050" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="eager" role="presentation"></p></div><figcaption>Photo by <a href="https://unsplash.com/@jakobnoahrosen?utm_source=medium&amp;utm_medium=referral" rel="noopener ugc nofollow" target="_blank">Jakob Rosen</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral" rel="noopener ugc nofollow" target="_blank">Unsplash</a></figcaption></figure><p id="a503">이번 글은 Java 나 Kotlin 을 다루는 개발자라면 수없이 마주쳤을 Exception 에 대해 이야기할텐데요. Exception 에 대한 자세한 개념이나 Exception 처리 practice 에 대해 코드레벨로 다루기 보다는 제가 평소에 Exception 을 다루면서 느꼈던 견해를 짤막하게 다루려고 합니다. 😎</p><h2 id="6593">Exception 이란?</h2><p id="a1b8">먼저, Exception 이라는 영어단어의 본래 뜻부터 짚고 넘어갈게요.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/0*Nrp60EjdiKejK0qS.png" width="700" height="476" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="lazy" role="presentation"></p></div></figure><p id="8b82">Exception 이라는 단어의 사전적 의미는 ‘<strong>예외</strong>’ 입니다. 그리고 우리말에서 예외란 <strong>‘일반적인 규칙에서 벗어난 것’</strong>을 말하죠. 그럼 Java 에서 Exception 클래스는 어떤 의미를 지닐까요?</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/0*dlFb_AhBgIPtFQWU.png" width="700" height="371" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 700px" loading="lazy" role="presentation"></p></div></figure><p id="b8ab">자바에서 Exception 이란 개발자가 예상한, 혹은 예상하지 못한 동작을 다루기위해 고안해낸 장치입니다. 코드는 하루가 멀다하고 비대해졌고 사람(개발자)이 코드가 동작하는 모든 경우의 수를 하나하나 예상하고 대비하는 것은 불가능해졌습니다. 그래서 예상치못하게 동작할 수 있는 코드는 Exception 을 발생하게 하고 개발자는 이에 대비할 수 있게했죠.</p><h2 id="8860">CheckedException 과 UncheckedException</h2><p id="30bb">자바에서는 특이하게 Exception 을 다시 두가지 큰 부류로 나눕니다. CheckedException 과 UncheckedException 이 바로 그것인데요.</p><figure><p><img alt="" src="https://miro.medium.com/max/1176/0*zF6TMJosnTic6Fiv.png" width="588" height="296" sizes="(min-resolution: 4dppx) and (max-width: 700px) 50vw, (-webkit-min-device-pixel-ratio: 4) and (max-width: 700px) 50vw, (min-resolution: 3dppx) and (max-width: 700px) 67vw, (-webkit-min-device-pixel-ratio: 3) and (max-width: 700px) 65vw, (min-resolution: 2.5dppx) and (max-width: 700px) 80vw, (-webkit-min-device-pixel-ratio: 2.5) and (max-width: 700px) 80vw, (min-resolution: 2dppx) and (max-width: 700px) 100vw, (-webkit-min-device-pixel-ratio: 2) and (max-width: 700px) 100vw, 588px" loading="lazy" role="presentation"></p></figure><p id="dc18">이 둘의 정의는 간단합니다. CheckedException 은 Exception 클래스를 직접 상속한 모든 클래스를 말하고, UncheckedException 은 RuntimeException 클래스를 상속한 모든 클래스를 말합니다.</p><p id="f18a">RuntimeException 이 UncheckedException 으로 불리게 된 이유는 RuntimeException 을 상속한 Exception 들은 컴파일타임에 그 처리를 강제하지 않아서 런타임에 확인할 수 있기때문입니다. 반대로 CheckedException 은 그 처리를 컴파일타임에 강제하기 때문에 그런 이름이 붙었죠.</p><h2 id="1bf3">CheckedException 은 정말 필요한가?</h2><p id="0e8e">이번 글에서 중요하게 다루고 싶은 이야기입니다. CheckedException 은 꼭 필요한걸까요?</p><p id="08d7">CheckedException 은 예전 자바 API 에서 주로 많이 발생시키던 Exception 입니다. 위에서 설명했듯이 IDE 에서 throw 를 명시해줘야 하고 catch 가 강제되죠. 라이브러리 개발자들이 <strong>이 메소드는 Exception 이 날 수 있으니 대응을 해라!</strong> 는 의미로 많이 사용했던 것 같습니다.</p><p id="6778"><strong>하지만 이를 강제하는 것이 옳을까요?</strong> <br>대부분의 CheckedException 은 대응이 불가능합니다. CheckedException 의 대표적인 예시인 SQLException 은 특히나 더 그렇죠. SQLException 은 쿼리의 문법이 잘못되었거나, 데이터 처리 과정에서 문제가 생겼거나, 디비 자체에 문제가 생겼거나, 네트워크에 문제가 생겼을 경우 발생합니다. 이 모든 경우는 애플리케이션에서 대응이 사실상 불가능합니다. 문제가 발생했음을 클라이언트에 알리고 해당 트랜잭션을 롤백하는 것이 현명한 처사일 것 같습니다. <br>하지만 지금의 CheckedException 은 그렇지 않죠. catch 를 강제하며 spring framework 에서는 기본적으로 트랜잭션을 롤백하지 않습니다. 대응을 강제하니 자동 롤백을 하지 않는 것이 CheckedException 의 본래 설계 원칙에는 알맞을테니 spring 도 그렇게 설계된 것 같습니다. 위 같은 불만 때문에 최근의 자바 라이브러리들은 CheckedException 을 사용하지 않거나 더 로우 레벨에서 CheckedException 이 발생 하더라도 UncheckedException 으로 감싸서 위로 던지도록 설계되어있습니다. <a href="https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/stereotype/Repository.html" rel="noopener ugc nofollow" target="_blank">spring 에서도 </a><code><a href="https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/stereotype/Repository.html" rel="noopener ugc nofollow" target="_blank">@Repository</a></code><a href="https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/stereotype/Repository.html" rel="noopener ugc nofollow" target="_blank"> 어노테이션의 경우 그런 기능이 포함되어 있죠.</a></p><p id="30d0">엉클밥(Robert C. Martin)의 저서인 <a href="https://www.oreilly.com/library/view/clean-code-a/9780136083238/" rel="noopener ugc nofollow" target="_blank">CleanCode</a> 에 따르면 CheckedException 이란 개념을 사용하는 프로그래밍 언어는 자바가 유일하다고합니다. 이 책에서 마틴은 CheckedException 은 꼭 필요한 경우가 아니면 사용하지 말자고 주장하며 여러가지 근거를 제시합니다.</p><blockquote><p id="15dc">At the time, we thought that checked exceptions were a great idea; and yes, they can yield some benefit. However, it is clear now that they aren’t necessary for the production of robust software. C# doesn’t have checked exceptions, and despite valiant attempts, C++ doesn’t either. Neither do Python or Ruby. Yet it is possible to write robust software in all of these languages. Because that is the case, we have to decide — really — whether checked exceptions are worth their price.<br>- Robert C. Martin</p></blockquote><p id="d159">저명한 엔지니어인 Bruce Eckel 또한 CheckedException 에 대해 다음과 같이 말했습니다.</p><blockquote><p id="0b49"><em>Examination of small programs leads to the conclusion that requiring exception specifications could both enhance developer productivity and enhance code quality, but experience with large software projects suggests a different result — decreased productivity and little or no increase in code quality.<br>- </em>Bruce Eckel</p></blockquote><p id="0471">그리고 자바와 같이 JVM 을 사용하는 언어인 Kotlin 조차 <a href="https://kotlinlang.org/docs/exceptions.html#checked-exceptions" rel="noopener ugc nofollow" target="_blank">CheckedException 을 무시합니다.</a> 코틀린 개발진의 의도 또한 위에서 설명한 엔지니어들의 의견과 크게 다르지 않습니다.</p><p id="0577">물론 CheckedException 이 올바른 경우도 있습니다. 애플리케이션 로직에서 분명하게 개발자가 의도한 Exception 의 경우, 즉 대처 로직이 명확한 경우는 CheckedException 을 써도 무방하다고 생각합니다. OptimisticLock 과 같은 경우도 그러한데, 두 명의 사용자가 동시에 요청을 했고 조금 늦은 사용자가 OptimisticLock 때문에 요청이 실패했을 경우 요청을 다시 시도하라는 메시지를 띄우는 것도 <strong>명확한 대처 로직</strong>으로 볼 수 있으므로 CheckedException 을 발생시켜도 전혀 이상해보이지 않죠.</p><h2 id="f205">결론</h2><p id="f799">평소 코드를 작성하면서 Exception 을 던져야하거나 이에 대한 처리가 필요할 경우 CheckedException 과 UncheckedException 이 헷갈리고 어떤걸 사용하는게 옳을지 갈팡질팡하는 경우가 많았습니다. 그래서 이번에 자바의 Exception 에 대해 많은 자료를 찾아보고 나름대로의 생각을 조금 두서없이 주저리주저리 정리해봤습니다.</p><p id="b7df">결론을 내리자면,</p><blockquote><p id="a522"><em>“어떤 Exception 을 던져야 할 지 고민되거나 CheckedException 이 명백하게 필요한 경우가 아니라면 UncheckedException 을 선택하자”</em></p></blockquote><h2 id="57a6">Reference</h2><p id="08a4"><a href="https://docs.oracle.com/javase/8/docs/api/index.html?java/lang/Exception.html" rel="noopener ugc nofollow" target="_blank">Java Platform SE 8</a></p><p id="e82f"><a href="https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html" rel="noopener ugc nofollow" target="_blank">https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html</a></p><p id="8e44">[Clean Code: Error Handling](<a href="https://medium.com/@shley_ng/clean-code-error-handling-19fec47ad688#:~:text=Checked%20Exceptions&amp;text=If%20you%20throw%20a%20checked,changes%20on%20many%20higher%20levels.)" rel="noopener">https://medium.com/@shley_ng/clean-code-error-handling-19fec47ad688#:~:text=Checked Exceptions&amp;text=If you throw a checked,changes on many higher levels.)</a></p><p id="ef4f"><a href="https://velog.io/@sangmin7648/%EB%8B%B9%EC%8B%A0%EC%9D%98-Checked-Exception%EC%9D%80-%ED%95%84%EC%9A%94-%EC%97%86%EB%8B%A4" rel="noopener ugc nofollow" target="_blank">당신의 Checked Exception은 필요 없다</a></p><p id="9f9a"><a href="https://kotlinlang.org/docs/exceptions.html#the-nothing-type" rel="noopener ugc nofollow" target="_blank">https://kotlinlang.org/docs/exceptions.html#the-nothing-type</a></p></div></div>

Stories by allocProc on Medium

jaeyeong

Java의 Exception 에 대한 고찰
이번 글은 Java 나 Kotlin 을 다루는 개발자라면 수없이 마주쳤을 Exception 에 대해 이야기할텐데요. Exception 에 대한 자세한 개념이나 Exception 처리 practice 에 대해 코드레벨로 다루기 보다는 제가 평소에 Exception 을 다루면서 느꼈던 견해를 짤막하게 다루려고 합니다. 😎
Exception 이란?
먼저, Exception 이라는 영어단어의 본래 뜻부터 짚고 넘어갈게요.
Exception 이라는 단어의 사전적 의미는 ‘예외’ 입니다. 그리고 우리말에서 예외란 ‘일반적인 규칙에서 벗어난 것’을 말하죠. 그럼 Java 에서 Exception 클래스는 어떤 의미를 지닐까요?
자바에서 Exception 이란 개발자가 예상한, 혹은 예상하지 못한 동작을 다루기위해 고안해낸 장치입니다. 코드는 하루가 멀다하고 비대해졌고 사람(개발자)이 코드가 동작하는 모든 경우의 수를 하나하나 예상하고 대비하는 것은 불가능해졌습니다. 그래서 예상치못하게 동작할 수 있는 코드는 Exception 을 발생하게 하고 개발자는 이에 대비할 수 있게했죠.
CheckedException 과 UncheckedException
자바에서는 특이하게 Exception 을 다시 두가지 큰 부류로 나눕니다. CheckedException 과 UncheckedException 이 바로 그것인데요.
이 둘의 정의는 간단합니다. CheckedException 은 Exception 클래스를 직접 상속한 모든 클래스를 말하고, UncheckedException 은 RuntimeException 클래스를 상속한 모든 클래스를 말합니다.
RuntimeException 이 UncheckedException 으로 불리게 된 이유는 RuntimeException 을 상속한 Exception 들은 컴파일타임에 그 처리를 강제하지 않아서 런타임에 확인할 수 있기때문입니다. 반대로 CheckedException 은 그 처리를 컴파일타임에 강제하기 때문에 그런 이름이 붙었죠.
CheckedException 은 정말 필요한가?
이번 글에서 중요하게 다루고 싶은 이야기입니다. CheckedException 은 꼭 필요한걸까요?
CheckedException 은 예전 자바 API 에서 주로 많이 발생시키던 Exception 입니다. 위에서 설명했듯이 IDE 에서 throw 를 명시해줘야 하고 catch 가 강제되죠. 라이브러리 개발자들이 이 메소드는 Exception 이 날 수 있으니 대응을 해라! 는 의미로 많이 사용했던 것 같습니다.
하지만 이를 강제하는 것이 옳을까요? 
대부분의 CheckedException 은 대응이 불가능합니다. CheckedException 의 대표적인 예시인 SQLException 은 특히나 더 그렇죠. SQLException 은 쿼리의 문법이 잘못되었거나, 데이터 처리 과정에서 문제가 생겼거나, 디비 자체에 문제가 생겼거나, 네트워크에 문제가 생겼을 경우 발생합니다. 이 모든 경우는 애플리케이션에서 대응이 사실상 불가능합니다. 문제가 발생했음을 클라이언트에 알리고 해당 트랜잭션을 롤백하는 것이 현명한 처사일 것 같습니다. 
하지만 지금의 CheckedException 은 그렇지 않죠. catch 를 강제하며 spring framework 에서는 기본적으로 트랜잭션을 롤백하지 않습니다. 대응을 강제하니 자동 롤백을 하지 않는 것이 CheckedException 의 본래 설계 원칙에는 알맞을테니 spring 도 그렇게 설계된 것 같습니다. 위 같은 불만 때문에 최근의 자바 라이브러리들은 CheckedException 을 사용하지 않거나 더 로우 레벨에서 CheckedException 이 발생 하더라도 UncheckedException 으로 감싸서 위로 던지도록 설계되어있습니다. spring 에서도 @Repository 어노테이션의 경우 그런 기능이 포함되어 있죠.
엉클밥(Robert C. Martin)의 저서인 CleanCode 에 따르면 CheckedException 이란 개념을 사용하는 프로그래밍 언어는 자바가 유일하다고합니다. 이 책에서 마틴은 CheckedException 은 꼭 필요한 경우가 아니면 사용하지 말자고 주장하며 여러가지 근거를 제시합니다.
At the time, we thought that checked exceptions were a great idea; and yes, they can yield some benefit. However, it is clear now that they aren’t necessary for the production of robust software. C# doesn’t have checked exceptions, and despite valiant attempts, C++ doesn’t either. Neither do Python or Ruby. Yet it is possible to write robust software in all of these languages. Because that is the case, we have to decide — really — whether checked exceptions are worth their price.
- Robert C. Martin
저명한 엔지니어인 Bruce Eckel 또한 CheckedException 에 대해 다음과 같이 말했습니다.
Examination of small programs leads to the conclusion that requiring exception specifications could both enhance developer productivity and enhance code quality, but experience with large software projects suggests a different result — decreased productivity and little or no increase in code quality.
- Bruce Eckel
그리고 자바와 같이 JVM 을 사용하는 언어인 Kotlin 조차 CheckedException 을 무시합니다. 코틀린 개발진의 의도 또한 위에서 설명한 엔지니어들의 의견과 크게 다르지 않습니다.
물론 CheckedException 이 올바른 경우도 있습니다. 애플리케이션 로직에서 분명하게 개발자가 의도한 Exception 의 경우, 즉 대처 로직이 명확한 경우는 CheckedException 을 써도 무방하다고 생각합니다. OptimisticLock 과 같은 경우도 그러한데, 두 명의 사용자가 동시에 요청을 했고 조금 늦은 사용자가 OptimisticLock 때문에 요청이 실패했을 경우 요청을 다시 시도하라는 메시지를 띄우는 것도 명확한 대처 로직으로 볼 수 있으므로 CheckedException 을 발생시켜도 전혀 이상해보이지 않죠.
결론
평소 코드를 작성하면서 Exception 을 던져야하거나 이에 대한 처리가 필요할 경우 CheckedException 과 UncheckedException 이 헷갈리고 어떤걸 사용하는게 옳을지 갈팡질팡하는 경우가 많았습니다. 그래서 이번에 자바의 Exception 에 대해 많은 자료를 찾아보고 나름대로의 생각을 조금 두서없이 주저리주저리 정리해봤습니다.
결론을 내리자면,
“어떤 Exception 을 던져야 할 지 고민되거나 CheckedException 이 명백하게 필요한 경우가 아니라면 UncheckedException 을 선택하자”
Reference
Java Platform SE 8
https://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html
[Clean Code: Error Handling](https://medium.com/@shley_ng/clean-code-error-handling-19fec47ad688#:~:text=Checked Exceptions&text=If you throw a checked,changes on many higher levels.)
당신의 Checked Exception은 필요 없다
https://kotlinlang.org/docs/exceptions.html#the-nothing-type

Exception 에 대한 고찰

댓글