✅ 한 일

💻 수행한 것들

오늘의 TIL은 25일에 미처 쓰지 못한 내용까지 포함했습니다

• 2주차 미션 5일차: 페어 프로그래밍 with Shine

오전에는 2단계 PR의 리뷰가 끝나지 않아서 개인적으로 공부하는 시간을 가졌습니다. 학습 자료의 Java Exception에 대해서 공부했는데, 컴파일 타임 exception과 Runtime exception에 대해서 배울 수 있었습니다. 신기한 게, runtime exception은 throw나 try/catch 등의 예외처리를 하지 않아도 프로그램을 실행할 수 있었습니다.

하지만 일반 Exception은 예외처리를 하지 않으면 컴파일러가 알 수 있기 때문에 예외처리를 해주어야 했습니다. 이 부분을 자세히 공부해보려고 합니다.

• 김영한님 로드맵 구매

고민을 많이 했지만.. 영한님 강의의 퀄리티는 이미 경험했기 때문에 투자라고 생각하고 질렀습니다. 모든 강의를 사고 싶었지만, 우선은 JPA 로드맵 위주로 구매하고, 핵심 원리 기본편/고급편을 구매했습니다. MVC 실습편은 코드스쿼드 미션이나 프로젝트를 진행하면서 토비의 스프링으로 공부해볼 수 있지 않을까?하는 생각으로 그렇게 하였습니다. 나중에 필요하면 30% 이벤트 때 또 지르는걸로..

📝 배운 것들

예외처리에 관하여

예외처리 관련하여 자바의 정석 8장의 내용을 정독했다. 사실 기초 문법을 익힌 뒤부터는 자바의 정석을 잘 안 읽어보았는데, 블로그로 예외처리를 정리하는 것보다 한 번쯤 정독하고 넘어가는 것이 좋다고 생각했다.

컴파일 에러와 런타임 에러

• 컴파일 에러: 컴파일러가 소스코드를 컴파일하여 *.class 파일을 생성하는 과정에서 발생하는 에러 즉, 컴파일 에러가 발생하면 class파일이 생성되지 않기 때문에 프로그램을 실행할 수 없다.
• 런타임 에러: 정상적으로 컴파일이 완료된 class 파일을 실행하고, 프로그램이 동작하는 과정에서 발생하는 에러

예외와 에러

• 에러: 프로그램 코드에 의해서 수습될 수 없는 심각한 오류로, 프로그램이 비정상적으로 종료된다.
  • OutOfMemoryError: 메모리의 Heap 영역이 가득차서 더 이상 객체를 생성할 수 없어지는 상태
  • StackOverflowError: 메모리의 Stack 영역에 과도한 호출 스택이 쌓여 Heap 영역을 범람하는 상태
• 예외: 일단 발생하더라도 프로그램 코드에 의해서 수습될 수 있는 다소 미약한 오류, 프로그래머가 예외 처리를 통해 프로그램이 종료되는 것을 막을 수 있다.

예외 클래스의 분류

• Exception클래스와 RuntimeException을 제외한 그 자손들: 사용자의 실수와 같은 외적인 요인에 의해 발생하는 예외
• Runtime Exception 클래스와 그 자손들: 프로그래머의 실수로 발생하는 예외

예외 처리하기 - try/catch

이와 같이 에러는 어쩔 수 없지만, 예외는 프로그래머가 미리 이에 대한 처리를 해주어야 한다.

예외 처리의 정의: 프로그램 실행 시 발생할 수 있는 예외에 대비한 코드를 작성하는 것
목적: 프로그램의 비정상 종료를 막고, 정상적인 실행상태를 유지하는 것

즉, 발생할 수 있는 예외를 처리했지만 프로그램이 의도치 않게 종료되도록 방치한다면 제대로 예외를 처리하지 않았다고 볼 수 있다. (찔린다..)

발생한 예외를 처리하지 못하면, 프로그램은 비정상적으로 종료되고 처리되지 못한 예외는 JVM의 예외처리기(UncaughtExceptionHandler)가 받아서 예외의 원인을 화면에 출력한다.

catch문이 동작하는 방식은 다음과 같다. 예외가 발생하면, 발생한 예외에 해당하는 클래스의 인스턴스가 만들어진다. 이 때 예외가 발생한 코드가 try 블럭 내부라면 이 인스턴스를 가지고 처리할 수 있는 catch 블럭을 찾는다.

catch블럭의 () 내에 선언된 참조변수의 종류와 예외 인스턴스를 instanceof 연산자를 이용해서 true인 블럭이 나올 때까지 검사한다.

알다시피, Exception은 모든 예외의 조상이므로 Exception 참조변수를 처리하는 catch 블럭을 만들면 검사결과가 항상 true이므로 모든 예외를 잡아낼 수 있게 된다.

또한, JDK 1.7부터 multi catch를 지원한다. () 내에 서로 다른 예외를 |로 연결하면, 두 예외 모두 catch할 수 있다. 단, 부모와 자손 관계의 예외를 넣으면 무의미한 코드 방지를 위해 컴파일 에러가 발생한다.

// 멀티캐치 예시
try { 
	...
} catch (ExceptionA | ExceptionB e) {
	...
}

단, 멀티 캐치 내부에서는 컴파일 타임에 어떤 예외에 의해 catch 블럭 내부로 진입한 지 모르기 때문에 두 예외간 공통 멤버만 접근이 가능하다.

unchecked exception vs checked exception

학습 자료의 실습을 해보면서, 발견했던 내용이다.

기존에 IllegalArgumentException이 발생하던 부분을 Exception을 상속받은 custom exception으로 변경하는 부분이었다. 원래는 try/catch나 throw같은 예외 처리가 되지 않아도 컴파일이 가능했다. 그런데 내가 만든 예외로 변경하자 예외처리를 하라고 컴파일 에러가 발생했다. 뭐지? 하고 살펴보니 IllegalArgumentException는 Runtime exception이었다! 그래서 컴파일 타임에는 처리가 되어있지 않아도 에러가 발생하지 않았다.

런타임 예외의 정의처럼 프로그래머의 실수에 의해 발생하는 예외이기 때문에, 컴파일러가 이런 모든 경우의 수를 잡을 수가 없다. 아니면 '예외가 발생할 수도 있긴 한데 프로그래머가 완벽하게 짰겠지~'라고 생각하지 않았을까..

여튼 위의 분류에서 Exception의 자손들은 이렇게 컴파일 타임에 예외 처리가 되었는지 검사할 수 있기 때문에 checked exception이고, RuntimeException의 자손들은 컴파일러가 체크하지 않기 때문에 unchecked exception이다.

💪 좋은 점

• 예외 처리에 대해서 학습하면서 자바의 정석 한 챕터를 정독할 수 있었다.
• 샤인과 미션을 잘 마무리한 것 같다!

👀 아쉬운 점

• 금요일날 놀아서 좀 양심에 찔리지만.. 크게 아쉽진 않다!

🗒 개선 방향

• 잘 쉬면서 꾸준히 코딩하자~