Jay

package hello.jdbc.repository; import hello.jdbc.domain.Member; import hello.jdbc.repository.ex.MyDbException; import lombok.extern.slf4j.Slf4j; import org.springframework.jdbc.datasource.DataSourceUtils; import org.springframework.jdbc.support.JdbcUtils; import org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator; import org.springframework.jdbc.support.SQLExceptionTranslator; im..

아래와 같이 스프링 데이터 접근 예외 계층에 대한 그림을 보자. 스프링이 제공하는 예외 변환기는 아래와 같은 코드이다. => SQL ErrorCode를 직접 확인하는 방법 SpringExceptionTranslatorTest의 코드는 아래와 같다. @Slf4j public class SpringExceptionTranslatorTest { DataSource dataSource; @BeforeEach void init() { dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD); } @Test void sqlExceptionErrorCode() { String sql = "select bad grammer"; try { Connection ..

데이터를 DB에 저장할 때 같은 ID가 이미 데이터베이스에 저장되어 있다면, 데이터베이스는 오류 코드를 반환하고, 이 오류 코드를 받은 JDBC 드라이버는 SQLException 을 던진다. 그리고 SQLException 에는데이터베이스가 제공하는 errorCode 라는 것이 들어있다. 데이터베이스 오류 코드 그림을 보자. H2 데이터베이스의 키 중복 오류 코드 e.getErrorCode() == 23505 SQLException 내부에 들어있는 errorCode를 활용 => 데이터베이스에서 어떤 문제가 발생했는지 확인할 수 있다. H2 데이터베이스 예는 아래와 같다. 23505: 키 중복 오류 42000: SQL 문법 오류 키 중복 오류 코드(H2 데이터베이스 오류 코드는 여기를 참고 H2 DB: 2..

서비스 계층은 가급적 특정 구현 기술에 의존하지 않고 순수하게 유지하는 것이 좋다. MemberRepository 인터페이스를 도입해서 구현 기술을 쉽게 변경할 수 있게 해본다. 인터페이스를 도입하면 MemberService는 MemberRepository 인터페이스에만 의존하면 된다. 구현 기술을 변경하고 싶으면 DI를 사용해서 MemberService 코드의 변경 없이 구현 기술을 변경할 수 있다. MemberRepository 인터페이스 package hello.jdbc.repository; import hello.jdbc.domain.Member; public interface MemberRepository { Member save(Member member); Member findById(Stri..

언체크 예외 활용(런타임 예외 활용) 런타임 예외 사용 - 그림 SQLException을 런타임 예외인 RuntimeSQLException으로 변환 ConnectException 대신 RuntimeConnectException을 사용하도록 바꿈 런타임 예외이기 때문에 서비스, 컨트롤러는 해당 예외들을 처리할 수 없으면 별도 선언 없이 그냥 두면 됨. 런타임 예외 사용 변환 - 코드 - UncheckedAppTest package hello.jdbc.exception.basic; import org.testng.annotations.Test; import java.net.ConnectException; import java.sql.SQLException; public class UnCheckedAppTes..

체크 예외 vs 언체크 예외 언제 사용하면 좋을까? 기본 원칙은 다음 2가지이다. 기본적으로 언체크(런타임) 예외를 사용 체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용 체크 예외 예) => 계좌 이체 실패 예외 / 결제시 포인트 부족 예외 / 로그인 ID, PW 불일치 예외 100% 체크 예외로 만들어야 하는 것은 아니다. 다만 계좌 이체 실패처럼 매우 심각한 문제는 개발자가 실수로 예외를 놓치면 안된다고 판단할 수 있다. 이 경우 체크 예외로 만들어 두면 컴파일러를 통해 놓친 예외를 인지할 수 있다. 체크 예외 문제점 체크 예외는 컴파일러가 예외 누락을 체크해주기 때문에 개발자가 실수로 예외를 놓치는 것을 막아준다. 그래서 항상 명시적으로 예외를 잡아서 처리하거나, 처리할 수 없을 때는 ..

RuntimeException 과 그 하위 예외는 언체크 예외로 분류된다. 언체크 예외는 말 그대로 컴파일러가 예외를 체크하지 않는다는 뜻이다. 언체크 예외는 체크 예외와 기본적으로 동일하다. 차이가 있다면 예외를 던지는 throws 를 선언하지 않고, 생략할 수 있다. 이 경우 자동으로 예외를 던짐 체크 예외 vs 언체크 예외 체크 예외: 예외를 잡아서 처리하지 않으면 항상 throws 에 던지는 예외를 선언해야 한다. 언체크 예외: 예외를 잡아서 처리하지 않아도 throws 를 생략할 수 있다. 언체크 예외를 잡아서 처리하는 코드 try { repository.call(); } catch (MyUncheckedException e) { //예외 처리 로직 log.info("error", e); } 언..

체크 예외 예제를 만들어보자. @Test 어노테이션이 아래와 같이 나와야 하는데 import org.junit.jupiter.api.Test; 내가 지정한 어노테이션은 아래와 같다. 그래도 빌드는 잘된다. import org.testng.annotations.Test; package hello.jdbc.exception.basic; import lombok.extern.slf4j.Slf4j; import org.testng.annotations.Test; @Slf4j public class CheckedTest { @Test void checked_catch() { Service service = new Service(); service.callCatch(); } /** * Exception을 상속받은 ..

예외 계층의 그림은 아래와 같다. Object : 예외도 객체이다. 모든 객체의 최상위 부모는 Object 이므로 예외의 최상위 부모도 Object 이다. Throwable : 최상위 예외이다. 하위에 Exception 과 Error 가 있다 Error : 메모리 부족이나 심각한 시스템 오류와 같이 애플리케이션에서 복구 불가능한 시스템 예외이다. 애플리케이션 개발자는 이 예외를 잡으려고 해서는 안됨. 상위 예외를 catch 로 잡으면 그 하위 예외까지 함께 잡는다. 따라서 애플리케이션 로직에서는 Throwable 예외도 잡으면 안되는데, 앞서 이야기한 Error 예외도 함께 잡을 수 있기 때문에다. 애플리케이션 로직은 이런 이유로 Exception 부터 필요한 예외로 생각하고 잡으면 된다. 참고로 Err..

트랜잭션 AOP가 사용된 전체 흐름을 그림으로 정리 트랜잭션 AOP 적용 전체 흐름 선언적 트랜잭션 관리 선언적 트랜잭션 관리(Declarative Transaction Management) @Transactional 애노테이션 하나만 선언해서 매우 편리하게 트랜잭션을 적용하는 것을 선언적 트랜잭션 관리라 한다. 선언적 트랜잭션 관리는 과거 XML에 설정하기도 했다. 이름 그대로 해당 로직에 트랜잭션을 적용하겠다 하고 어딘가에 선언하기만 하면 트랜잭션이 적용되는 방식. 프로그래밍 방식의 트랜잭션 관리(programmatic transaction management) 트랜잭션 매니저 또는 트랜잭션 템플릿 등을 사용해서 트랜잭션 관련 코드를 직접 작성하는 것을 프로그래밍 방식의 트랜잭션 관리라 한다. 선언적..