qwef

우리가 앞서 커넥터 얻어오고, 바인딩하고, 커넥터 반환하고 이런 try catch 이 부분이 리포지토리의 crud 모든 부분에 들어갔다. 이런 반복 문제를 효과적으로 처리하는 방법은 템플릿 콜백 패턴을 사용하는 것이다. 스프링은 이미 JDBC 반복문제를 해결하기 위해 JdbcTemplate를 제공한다. 그냥 쓰면 된다. @Slf4j public class MemberRepositoryV5 implements MemberRepository{ private final JdbcTemplate template; public MemberRepositoryV5(DataSource dataSource) { this.template = new JdbcTemplate(dataSource); } @Override publ..

간단하다. @Slf4j public class MemberRepositoryV4_2 implements MemberRepository{ private final DataSource dataSource; private final SQLExceptionTranslator exTranslator; public MemberRepositoryV4_2(DataSource dataSource) { this.dataSource = dataSource; this.exTranslator = new SQLErrorCodeSQLExceptionTranslator(dataSource); } @Override public Member save(Member member){ String sql = "insert into member..

스프링은 저런 예외 관련한 문제에 지원을 해 주기 위해, 미리 데이터 접근과 관련된 예외를 추상화 하여 제공해 준다. 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 ..