[Share] 4주차 토론 내용

[hihiboss]

Topic

[토비의 스프링 3.1] 4장. 예외

@sojeongw 님 대신 정리해보았습니다. 내용이 미흡해도 양해 부탁드립니다..ㅎㅎ

Detail

예외처리 방법

예외처리 회피

아영

public void add() throws SQLException {
    // JDBC API
}

public void add() throws SQLException {
    try {
        // JDBC API
    }
    catch(SQLException e) {
        // 로그 출력
        throw e;
    }
}

위 두 방법의 차이를 모르겠다.

현식

굳이 아래와 같이 하는 이유는 로그를 찍어야 할 때가 있기 때문이다. 개인적으로 해당 메소드를 호출한 쪽에서 로그를 찍어도 상관없을 것 같다.

주만

내가 공부했을 때, try-catch 문은 코드를 안예쁘게 만들기 때문에 정말 예외 처리가 필요한 부분에서만 사용해야 한다고 배웠다. 현업에서 사용하다 보니 catch문이 하나만 사용되는 경우는 거의 없다. 예외를 처리하는 메소드를 호출한 부분도 예외를 알아야 할 때가 있어서 예외를 던지는 경우가 존재한다.

주형

예외 트레이스 남기려고 쓰는 것 같다.

현식

로그 찍을 때 해당 메소드 이름을 남기기 때문에 이렇게 하는 것 같다.

주형

e 변수 안에 스택으로 트레이스가 남기 때문에 왜 굳이 로그를 찍는지 고민해봤다. logger를 사용할 때 양식을 지정해야 하는 경우, 스택 트레이스를 파싱하기 힘들기 때문인 것 같다.

성재

디버깅용이라고 생각한다.

중첩 예외

아영

중첩 예외라는게 어떤건가요?

민수

책에서는 예외를 바꾸면 본래의 예외가 가지는 예외 코드 등이 사라지기 때문에 의도하는 예외에 이전 예외 정보를 함께 담는 것을 중첩 예외라고 한다.

현식

새 예외를 만들면서 생성자에 이전 예외를 넣어서 만드는 예외다. 이전 예외들도 까볼 수 있어서 더 섬세한 처리가 가능하다.

런타임 예외

아영

런타임 예외를 사용하면 어떤 점이 좋은가?

현식

try-catch문 안써도 되서 좋다.

주형

try-catch가 없으면 컴파일이 안된다. 이게 개발자에게 너무 귀찮기 때문에 런타임 예외로 전환하면 try-catch를 안써도 된다.

현식

런타임 예외는 코드를 잘 짜서 막을 수 없는 예외라고 본다. 그래서 try-catch를 강제하지 않고 애플리케이션을 죽이는 것 같다.

내가 개발하고 있는 서비스에서는 예외가 발생하면 UI로 띄워주기만 하면 되기 때문에 이런 경우 아니면 런타임 예외로 처리해도 될 것 같다.

주형

예외라는게 catch하는 입장에서 짜야하는 것 같다. 막 던지면 받는 사람이 어떻게 잡아야할지 애매할 수 있다.

이번 챕터 포인트

주형

"예외는 꼭 처리해야 한다"가 좋았다. 핸들링하는 사람이 어떻게 핸들링할지 예상하고 예외를 짜야한다고 생각한다.

성재

"예외 회피에는 의도가 분명해야 한다"가 너무 좋다. 확실한 건 잡고 아닌건 터트려야 한다.

주형

"기술에 독립적인", "기술과 무관한" 과 같은 용어에 대해 생각하면 좋을 것 같다. 비즈니스하는 사람과 개발하는 사람이 같은 용어로 소통하기 위해서 기술과 독립적이여야 한다. 비즈니스 로직과 기술적인 부분을 분리하여 순수한 요구사항만을 로직으로 구현해라라는 말이 기술과 독립적이여야 한다는 뜻인 것 같다.

[sojeongw]

저도 아영님 첫번째 질문이 궁금했는데! 이번 주도 재밌는 대화를 많이 하셨네요 굿굿!