[2025 백엔드] 헤드퍼스트자바 독서 #9 - 13장. 위험한 행동

마치사 (마치가 예뻐서 사망했다는 뜻)

ㅎㅇ

원래 GDG 프로젝트 개발을 좀 해야하는데 책을 좀 더 읽어보고자.. 지금 16시니까 한 2시간 정도 읽고 개발 와바박하면 되지 않을까

---

그래도 예외처리는 좀 더 난이도가 낮지 않을까싶긴하다 try-catch문은 어느정도 쓸 수 있고 예외이름만 좀 알아두면 되지 않을까? 전역Exception 처리도 지금은 해주니까뭐...

 

추가로 이 책을 읽을 때 목표를 GUI 직전까지로 삼았는데 이제 13장. 14장이 GUI기 때문에 목표한 마지막 부분이다. 근데 뒤에 멀티스레드니 뭐니하는 부분은 좀 읽어야할 필요가 있어서 좀 더 읽을 예정이다.

 

우선 13장은 GUI와 JavaSound API 가 같이 나오기 때문에 이 부분은 걷어내고 예외처리 부분만 좀 읽어보기로한다.

GUI라는게 데스크톱 어플리케이션 개발에는 필요하다만 우선은 내가 하고 있는 웹개발과 모바일 앱 개발에는 별로 쓰이지 않으므로 우선 패스. 다음에 데스크톱 어플리케이션 개발할 때 한 번 알아보기로 한다.

 

예외처리 메커니즘은 호출할 메서드가 예외를 발생할 수도 있다는 것을 선언해야한다. 이 때는 예외를 발생시킬 수 있는, 위험한 메서드를 호출하는 메서드의 선언부에 throws 구문을 넣으면 된다. 예외를 터지는 코드에 throws 부분을 선언하면(예외 선언) 되고 그 코드 (메서드)를 불러오는 부분에 try-catch문을 쓰면 된다.

 

메서드 호출부분에 throws에는 여러 개의 에러를 선언해도 된다.

 

예외는 언제나 메서드를 호출한 곳으로 던져진다. 던지는 메서드에서

---

try-catch

컴파일러는 try-catch문을 사용해 위험한 코드를 작성하면 예외가 터져도 그냥 넘어간다. try 부분에 예외가 터지지 않으면 실행할 코드들이 들어가고, catch 부분에 예외가 터질 때 실행할 구문이 들어간다.

 

try {
	//로직
} catch (Exception e) {
	//로직
}

이런 식으로 구성된다.

 

Exception 역시 객체다. 상위클래스로는 Throwable을 두고 하위클래스로는 IOException, InterruptedException, RuntimeException을 둔다. RuntimeException의 하위클래스로 NullPointerException 등 런타임에러들이 있다. 컴파일러는 RuntimeException을 제외한 에러를 감지하고 에러를 터뜨린다. RuntimeException은 try/catch 블록을 사용하거나 선어부에 throws 구문이 있는지 여부에 상관없이 어디서든 사용할 수 있고, 터뜨릴 수 있다. 

 

그렇기 때문에 Custom Exception을 만들고 Exception을 확장하도록하면 Custom Exception 클래스 파일만 만들면 나머지는 알아서 Exception 객체에서 상속받아서 진행할 수 있다.

 

Exception과 하위클래스들은 Throwable 클래스에서 getMessage() 메서드와 printStackTrace() 메서드를 상속받는다.

---

try-catch 문에서의 흐름제어

try {
	//로직
} catch (BadSqlGrammerException BE) {
	//로직
} catch (UnauthorizedException UE) {
	//로직
} finally {
	//로직
}

System.out.println("완뇨");

와 같은 형식으로 이루어질 수 있다.

Exception 역시 객체이기에 다형성을 이용할 수 있어 catch 블록에 오류를 Exception ex로만 설정해두면 모든 에러를 잡아낼 수 있다. 하지만 어떤 문제가 있는지는 알 수 없으므로 별도의 catch 블럭을 만들어줘야한다.

 

catch 블럭을 여러 개 사용해야할 때는 Exception의 상속체계에서 가장 아래 것부터 위로 올라가야한다. 즉 가장 하위 클래스에서 상위클래스로 올라가야한다. Excpetion - MemberException - InvalidAgeException / InvalidNameException이 있다고 할 때, InvalidNameException이나 InvalidAgeException부터 catch 문에서 잡아내야한다는 것. 만약 catch문에서 MemberException부터 온다면 InvalidNameException이나 InvalidAgeException이나 상관없이 모두 catch 문에 걸리게 되고 각 에러게 알맞는 처리를 할 수가 없다.

 

추가로 이미 MemberException 을 catch 블럭에 넣었는데 이후의 catch 문의 MemberException 의 하위클래스인 InvalidAgeException이 들어오면 컴파일에러가 터진다. 따라서 상속관계의 Exception catch 블럭의 경우에는 catch 블럭에서의 처리가 필요한 가장 하위클래스의 Exception부터 상위클래스의 Exception으로 올라가야한다. 단, InvalidAgeException과 InvalidNameException 간은 순서 상관없이 쓰면 된다.

 

try가 성공하면 catch문들은 시행되지 않고, 에러가 터지면 catch 문에서 설정한 에러에 맞춰서 로직을 수행한다. try의 나저미 부분은 실행되지 않는다.

 

예외 발생과 관련없는 부분은 finally 블록에 넣으면 된다. finally 블록은 무조건 실행된다.

---

스택에서 어떤 일이 발생하는가?

자세한 것은 헤드퍼스트자바 13장 484쪽을 참고하면 된다. 거기 그림이 있다.

메서드가 실행되면 스택에 쌓이게 되는데, 최상위 스택프레임에서 실행 중인 메서드에서 예외가 터지면 (당연히도 최상위 스택프레임이 실행 중이니..) 그즉시 그 메서드는 실행이 중지되고 스택에서 제거된다. 그리고 그 에러는 다시 그 스택 바로 밑 메서드로 전해진다. (예외가 터진 메서드를 호출한 메서드)

 

이러면 밑의 메서드, 그니까 예외가 터진 메서드를 호출한 메서드는 메서드 선언부분에 에러를 throws 해서 그 밑에 메서드로 (즉 예외가 터진 메서드를 호출한 메서드를 호출한 메서드) 예외를 전달하거나(회피하거나) try-catch 문으로 처리할 수 있다.

 

결국에는 폭탄돌리기 같은 느낌인데 에러를 피하는 방식으로 계속 가다보면 최종적으로는 main 메서드에서 try-catch 문을 통해 에러를 처리해야한다.

 

 

후아~

전역Exception vs try-catch

try-catch는 그렇게 어려운 내용도 아니고 복잡한 내용도 아니라서 금방금방 넘어갔다. 분량도 적고 60~70%는 GUI 기초 관련된 내용이라서 패스했다. 어쨌든 나중에 GUI 필요할 때 읽어보긴 할 것이다만.. 우선은 패스