Jay

체크 예외 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) 트랜잭션 매니저 또는 트랜잭션 템플릿 등을 사용해서 트랜잭션 관련 코드를 직접 작성하는 것을 프로그래밍 방식의 트랜잭션 관리라 한다. 선언적..

트랜잭션 AOP를 사용하는 새로운 서비스 클래스를 만들어보자.(MemberServiceV3_3) package hello.jdbc.service; import hello.jdbc.domain.Member; import hello.jdbc.repository.MemberRepositoryV3; import lombok.RequiredArgsConstructor;import lombok.extern.slf4j.Slf4j; import org.springframework.transaction.annotation.Transactional; import java.sql.SQLException; /** * 트랜잭션 - @Transactional AOP */ @Slf4j @RequiredArgsConstructor ..

프록시 도입 전 프록시를 도입하기 전에 기존처럼 서비스의 로직에서 트랜잭션을 직접 시작 서비스 계층의 트랜잭션 사용 코드 예시 //트랜잭션 시작 TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition()); try { //비즈니스 로직 bizLogic(fromId, toId, money); transactionManager.commit(status); //성공시 커밋 } catch (Exception e) { transactionManager.rollback(status); //실패시 롤백 throw new IllegalStateException(e); } 프록시 도입 후 프록시 사용 시 트랜..

트랜잭션 매니저의 전체 동작 흐름을 자세히 보자. 트랜잭션 매니저 1 - 트랜잭션 시작 클라이언트의 요청으로 서비스 로직을 실행 서비스 계층에서 transactionManager.getTransaction() 을 호출해서 트랜잭션을 시작한다. 트랜잭션을 시작하려면 먼저 데이터베이스 커넥션이 필요하다. 트랜잭션 매니저는 내부에서 데이터소스를 사용해서 커넥션을 생성한다. 커넥션을 수동 커밋 모드로 변경해서 실제 데이터베이스 트랜잭션을 시작한다. 커넥션을 트랜잭션 동기화 매니저에 보관한다. 트랜잭션 동기화 매니저는 쓰레드 로컬에 커넥션을 보관한다. 따라서 멀티 쓰레드 환경에 안전하게 커넥션을 보관할 수 있다. 트랜잭션 매니저2 - 로직 실행 서비스는 비즈니스 로직을 실행하면서 리포지토리의 메서드들 호출. 이 ..

MemberRepositoryV2를 복사해서 MemberRepositoryV3를 만들자. 커넥션을 가져오는 부분을 아래와 같이 변경해준다 private void close(Connection con, Statement stmt, ResultSet rs) { JdbcUtils.closeResultSet(rs); JdbcUtils.closeStatement(stmt); // 주의! 트랜잭션 동기화를 사용하려면 DataSourceUtils를 사용해야 한다. DataSourceUtils.releaseConnection(con, dataSource); } private Connection getConnection() throws SQLException { // 주의! 트랜잭션 동기화를 사용하려면 DataSourc..

트랜잭션 추상화 인터페이스는 아래와 같다. public interface TxManager { begin(); commit(); rollback(); } 트랜잭션은 사실 단순하다. 트랜잭션을 시작하고, 비즈니스 로직의 수행이 끝나면 커밋하거나 롤백 그리고 아래와 같이 인터페이스 기반으로 각각 기술에 맞게 구현체를 만든다. JdbcTxManager: JDBC 트랜잭션 기능을 제공하는 구현체 JpaTxManager: JPA 트랜잭션 기능을 제공하는 구현체 트랜잭션 추상화와 의존관계 서비스는 특정 트랜잭션 기술에 직접 의존하는 것이 아니라, TxManager이라는 추상화된 인터페이스에 의존. 원하는 구현체를 DI를 통해서 주입하면 된다. JDBC 트랜잭션 기능이 필요하면 JdbcTxManager이라는 서비스에..