qwef

스프링은 저런 예외 관련한 문제에 지원을 해 주기 위해, 미리 데이터 접근과 관련된 예외를 추상화 하여 제공해 준다. DataAccessException은 추상 클래스 이다. 저 예외들은 특정 기술에 종속적이지 않게 설계가 되어, 서비스 계층에서도 사용하면 된다. 또, JDBC나 JPA를 사용할 때 발생하는 예외를 스프링이 제공하는 예외로 변환해 주는 역할도 스프링이 제공해 준다. 스프링이 제공하는 데이터 접근 계층 예외는 크게 2가지로 구분되는데, NonTransient와 Transient다. 직역은 일시적인 이란 뜻인데, 보면 transient 하위로 timeout등이 있는데, 말 그대로 일시적 오류라 다시 시도했을 때 성공할 가능성이 있는 것이다. 반대로 NonTransient는 잘못된 sql이라던..

아마도 SQLException 이런 걸 직접 만든다는 뜻 같다. DB오류에 따라서 사실 복구 가능한 경우는 많이 있지는 않지만, 복구 하고 싶은 경우가 있다. 예를 들면 계정을 새로 생성하는데 DB에 이미 같은 id가 있으면 이 id뒤에 뭔가를 덧붙여 만드는.. 그 외 우리가 id확인이나 닉네임 확인 할 때 같은 거 있으면 뒤에 뭐 붙여서 추천해주는 그런 경우 있는데, 그런건가봄. 날리는 오류코드도, 같은 SQLException이지만 오류의 종류에 따라 오류 코드 같은 것을 보내준다. 이것도 DB에 따라 다르긴 한데, H2같은 경우는 Primary Key를 사용한 것에 같은 걸 생성하려 든다면 23505이다. 42000은 sql 문법 오류. 이건 e.getErrorCode() 해보면 읽을 수 있다. 그럼..

먼저, 우리가 바꿔 줄 커스텀 예외를 만든다. public class MyDbException extends RuntimeException{ public MyDbException() { } public MyDbException(String message) { super(message); } public MyDbException(String message, Throwable cause) { super(message, cause); } public MyDbException(Throwable cause) { super(cause); } } 생성자는 그냥 빈거, 메시지 넣을 수 있는 거, 그리고 바꿔서 던지기 전의 예외가 어디서 부터 온 예외인지 같이 첨부해서 던지기 위해서는 Throwable이 반드시 필요하다..

먼저 체크예외로 해결하려는 시도를 한다.. 안 좋긴 하지만 시키려는 모양이다. 우리가 먼저, @Transactional public void accountTransfer(String fromId, String toId, int money) throws SQLException { Member fromMember = memberRepository.findById(fromId); Member toMember = memberRepository.findById(toId); memberRepository.update(fromId, fromMember.getMoney() - money); validation(toMember); memberRepository.update(toId, toMember.getMoney() ..

이제 언체크 예외를 쓸 것이다. 언체크 예외를 쓰면 이제 명시적으로 예외를 던져 줄 필요가 없다. 그럼 이제 코드도 깔끔해지고 더 이상 SQLException 같은 특정기술의 예외에 의존을 하지 않아도 된다. public class UnCheckedAppTest { @Test public void unChecked(){ Controller controller = new Controller(); assertThatThrownBy(()-> controller.request()) .isInstanceOf(Exception.class); } static class Controller{ Service service = new Service(); public void request(){ service.logic()..

일단 기본적으로 언체크 예외를 사용을 한다. 체크예외는 비즈니스 로직상 의도적으로 던지는 경우에만 주로 사용한다. 계좌이체 실패, 결제 시 포인트 부족, 로그인 id, pw 불일치 등 조금 뭐랄까 의도적으로 처리할 일이 있는? 이런 경우는 고객에게 알리거나 등. 물론 위의 경우도 100% 체크 예외로 만들어야 하는 것은 아님. 근데, 예를 들어 계좌 이체처럼 매우 심각한 문제는 이런 개발자가 놓치면 안되는 예외는 체크 예외로 해 두면 컴파일러가 인지할 수 있음. 체크 예외는 뭔가 개발자가 의도적으로 인지하고 싶을 때, 처리하고 싶을 때 컴파일러가 잡아주므로 보통은 런타임예외(언체크예외)를 주로 씀. 저렇게 의도적으로 인지하거나 처리하고 싶을 경우를 제외 하고는. 아, 이거는 에러 나면 ~~ 이렇게 처리하..

체크예외 : 예외를 잡아서 처리하지 않으면 항상 throws 해서 위에 던져야 한다. 언체크 예외 : 예외를 잡아서 처리하지 않아도 throws를 생략할 수 있다. 알아서 던져진다. @Slf4j public class UncheckedTest { Service service = new Service(); @Test public void unchecked_catch(){ service.callCatch(); } @Test public void unchecked_throw(){ assertThatThrownBy(()->service.callThrow()).isInstanceOf(MyUncheckedException.class); } static class MyUncheckedException extends ..

이거는 스프링에 대한 것 이라기 보다는, 스프링이 제공해주는 테스트 기능을 이용해서 예외 그냥 일부로 던져보는 거임. @Slf4j public class CheckedTest { @Test void checked_catch(){ Service service = new Service(); service.callCatch(); } @Test void checked_throw() throws MyCheckedException { Service service = new Service(); assertThatThrownBy(()->service.callThrow()).isInstanceOf(MyCheckedException.class); } static class MyCheckedException extends ..

예외는 폭탄 돌리기와 같음. 잡아서 처리하거나, 처리할 수 없으면 밖으로 던져야 함. 예외를 처리 못하고 계속 던지면, 보통 애플리케이션의 경우 main까지 오면 그냥 예외 로그 출력하고 시스템 죽임. 웹 애플리케이션의 경우, 서버가 죽으면 안되니까 보통 WAS가 처리 함. 주로 우리가 앞서 MVC2에서 했던 개발자가 지정한 오류페이지를 응답하거나 log를 남기거나.

스프링 강의지만 자바 예외에 대해 복습한다고 한다. 체크예외, 언체크 예외 위주로 설명할 듯 싶다. Error는 메모리 부족, 시스템 오류 등 복구가 아예 불가능한 것. 예외처리 해서 될 수 있는 게 아닌 듯. 그래서 예외처리는 Exception부터 체크예외는 컴파일러가 체크하는 예외. 그러니까 왜 예외처리 안하면 컴파일러가 예외처리 throw 하거나 try catch 하라고 에러처리 하는.. 언체크 예외는 이러 한 체크를 안하는 에러 라고 함. 복구 가능성이 없는 예외들이라 그렇다고 함. Error도 마찬가지로 언체크 예외임. Exception 중 런타임예외부터도 언체크예외라고 함.