• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    해결됨

예외를 전환할떄 기존 예외 포함이 무슨 말인가요?

24.05.07 00:56 작성 조회수 127

0

체크예외에서 런타임 예외로 변경할 때 cause 생성자를 포함 해야한다는 의미인건가요?

그리고 기존 예외가 포함된다는게 어떤 말인지 잘 모르겠습니다. 어떻게 기존 예외가 포함이 되는건가요? 또 예외출력 로그를 보고 어디가 문제인지 어떻게 판단하고 수정을 하는건가요?

답변 2

·

답변을 작성해보세요.

0

y2gcoder님의 프로필

y2gcoder

2024.05.07

안녕하세요. 양치잘하기님, 공식 서포터즈 y2gcoder입니다. 

AI 답변을 참고해주시고, 추가로 궁금한 사항은 제 댓글의 답글 혹은 질문을 새로 남겨주세요 🙂

감사합니다.

static class Repository{
    public void call()  {
        try {
            runSQL();
        } catch (SQLException e) {
            throw new RuntimeSQLException(e);
        }
    }

이 코드 부에서 예외 전환이 try-catch문에서 catch로 예외를 잡고 catch문 안에

throw new RuntimeSQLException(e);

이 코드로 예외를 전환한 다음에 매개변수 e 를 이용해 기존 예외를 포함하게 하는것으로 이해 하였습니다.

매개변수를 사용해주어서

'RuntimeSQLException 클래스의 cause가 사용된 생성자로 인해 SQLException으로 인해 발생된 예외인것을 확인 가능하고 그 예외를 RuntimeSQLException예외로 변경하였다.'

라는것으로 이해를 하였는데 맞게 이해한것이 맞을까요?

또 예외출력 로그를 보면

Caused by: java.sql.SQLException: ex

at hello.jdbc.exception.basic.UnCheckedAppTest$Repository.runSQL(UnCheckedAppTest.java:67)

at hello.jdbc.exception.basic.UnCheckedAppTest$Repository.call(UnCheckedAppTest.java:60)

... 71 common frames omitted

이렇게 출력이 되는데 이 정보만으로 무엇이 문제인지 어떻게 확인하고 수정을 하는건가요?

 

추가로

https://www.inflearn.com/questions/1259058/%EC%A4%91%EC%9A%94%ED%95%9C-%EB%9F%B0%ED%83%80%EC%9E%84-%EC%98%88%EC%99%B8%EB%A5%BC-%EC%95%88%EC%9E%A1%EC%95%84%EC%A3%BC%EB%A9%B4-%EC%8B%9C%EC%8A%A4%ED%85%9C%EC%9D%80-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%90%98%EB%82%98%EC%9A%94
이 질문에서 런타임 예외를 잡지 않으면 고객에게 어떻게 서비스가 보여지는지 궁금합니다.

예외를 잡지 않아서 오류메시지를 출력할 수 없을텐데 예외를 잡지 않은상태에서 예외가 발생하면 고객에게는 어떻게 서비스가 보여지나요?

y2gcoder님의 프로필

y2gcoder

2024.05.07

이 코드 부에서 예외 전환이 try-catch문에서 catch로 예외를 잡고 catch문 안에

throw new RuntimeSQLException(e);

이 코드로 예외를 전환한 다음에 매개변수 e 를 이용해 기존 예외를 포함하게 하는것으로 이해 하였습니다.

매개변수를 사용해주어서

'RuntimeSQLException 클래스의 cause가 사용된 생성자로 인해 SQLException으로 인해 발생된 예외인것을 확인 가능하고 그 예외를 RuntimeSQLException예외로 변경하였다.'

라는것으로 이해를 하였는데 맞게 이해한것이 맞을까요?

=> 잘 이해하셨다고 생각합니다!

또 예외출력 로그를 보면

Caused by: java.sql.SQLException: ex

at hello.jdbc.exception.basic.UnCheckedAppTest$Repository.runSQL(UnCheckedAppTest.java:67)

at hello.jdbc.exception.basic.UnCheckedAppTest$Repository.call(UnCheckedAppTest.java:60)

... 71 common frames omitted

이렇게 출력이 되는데 이 정보만으로 무엇이 문제인지 어떻게 확인하고 수정을 하는건가요?

=> 맞습니다! cause 에 넣어주면 해당 예외의 근본 원인까지 추적할 수 있습니다. 위에서도 어느 위치에서 예외가 발생했는지 보여주고 있습니다! 위의 정보를 통해 예외의 원인을 파악하고 해결할 수 있습니다!

추가로

https://www.inflearn.com/questions/1259058/%EC%A4%91%EC%9A%94%ED%95%9C-%EB%9F%B0%ED%83%80%EC%9E%84-%EC%98%88%EC%99%B8%EB%A5%BC-%EC%95%88%EC%9E%A1%EC%95%84%EC%A3%BC%EB%A9%B4-%EC%8B%9C%EC%8A%A4%ED%85%9C%EC%9D%80-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%90%98%EB%82%98%EC%9A%94
질문에서 런타임 예외를 잡지 않으면 고객에게 어떻게 서비스가 보여지는지 궁금합니다.

예외를 잡지 않아서 오류메시지를 출력할 수 없을텐데 예외를 잡지 않은상태에서 예외가 발생하면 고객에게는 어떻게 서비스가 보여지나요?

=> @ExceptionHandler 등으로 잡아주지 않았다면 스프링에서 자체적으로 요청 헤더 타입에 따라 기본 에러 페이지나 에러 API 응답을 리턴해주게 되어 있습니다! 자세한 내용은 영한님의 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 을 학습하시길 권해드립니다! 간단하게만 보여드리자면 JSON 요청에 대한 기본 예외 응답은

{
     "status": 500,
     "error": "Internal Server Error",
     "exception": "java.lang.IllegalArgumentException",
     "path": "/api/members/bad"
}

이런 느낌입니다!

0

인프런 AI 인턴님의 프로필

인프런 AI 인턴

2024.05.07

안녕하세요, 인프런 AI 인턴입니다.

양치잘하기님의 질문에 대해, “체크 예외를 언체크(런타임) 예외로 전환할 때 cause 생성자를 이용하는 의미”와 관련하여, 이미 답변된 유용한 정보를 찾았습니다. 해당 내용은 체크 예외를 런타임 예외로 변환하는 과정에서 원본 예외의 정보를 보존하기 위해 cause 생성자를 사용하는 방법에 대해 설명하고 있습니다.

  • 체크 예외를 언체크 예외로 전환하면서, “cause” 생성자를 사용하는 것은 기존 예외 정보(원인)을 새로운 예외 객체에 포함시켜 예외 체이닝을 가능하게 하는 방법입니다. 이는 예외가 발생했을 때 스택 트레이스에 원본 예외 정보가 함께 표시되게 하여, 디버깅과 예외 처리에 도움을 줍니다.

자세한 설명을 원하신다면 아래 링크를 참조하시기 바랍니다:

이 질문과 답변은 예외를 런타임 예외로 전환하는 과정에서 원본 예외를 포함하는 방법과 이유, 그리고 예외 로그를 통해 문제를 어떻게 파악하고 수정해 나가는지에 대한 내용을 다루고 있습니다. 예외 전환 시 원본 예외 정보를 보존하는 것은 문제를 더 쉽게 분석하고, 코드의 버그를 수정하는 데 도움이 됩니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.