내가 기억하려고 만든 블로그 내가 기억하려고 만든 블로그

예외 포함과 스택 트레이스 예외를 전환할 때는 꼭! 기존 예외를 포함해야 한다. 그렇지 않으면 스택 트레이스를 확인할 때 심각한 문제가 발생한다. package hello.jdbc.exception.basic; import lombok.extern.slf4j.Slf4j; import org.junit.jupiter.api.Test; import java.sql.SQLException; import static org.assertj.core.api.Assertions.assertThatThrownBy; @Slf4j public class UnCheckedAppTest { @Test void printEx() { Controller controller = new Controller(); try { contr..

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

체크 예외 기본 이해 Exception과 그 하위 예외는 모두 컴파일러가 체크하는 체크 예외이다. 단 RuntimeException은 예외로 한다. 체크 예외는 잡아서 처리하거나, 또는 밖으로 던지도록 선언해야 한다. 그렇지 않으면 컴파일 오류가 발생한다. 체크 예외 전체 코드 - CheckedTest test/java/hello/jdbc/exception/basic/CheckedTest 생성 package hello.jdbc.exception.basic; import lombok.extern.slf4j.Slf4j; import org.junit.jupiter.api.Test; import static org.assertj.core.api.Assertions.*; @Slf4j public class Ch..

예외 계층 스프링이 제공하는 예외 추상화를 이해하기 위해서는 먼저 자바 기본 예외에 대한 이해가 필요하다. 예외는 자바 언어의 기본 문법에 들어가기 때문에 대부분 아는 내용일 것이다. 예외의 기본 내용을 간단히 복습하고, 실무에 필요한 체크 예외와 언체크 예외의 차이와 활용 방안에 대해서도 알아보자. 예외 계층 예외 계층 그림 Object : 예외도 객체이다. 모든 객체의 최상위 부모는 Object이므로 예외의 최상위 부모도 Object이다. Throwable : 최상위 예외이다. 하위에 Exception과 Error가 있다. Error : 메모리 부족이나 심각한 시스템 오류와 같이 애플리케이션에서 복구 불가능한 시스템 예외이다. 애플리케이션 개발자는 이 예외를 잡으려고 해서는 안된다. 상위 예외를 ca..

스프링부트의 자동 리소스 등록 스프링 부트가 등장하기 이전에는 데이터소스와 트랜잭션 매니저를 개발자가 직접 스프링 빈으로 등록해서 사용했다. 그런데 스프링 부트로 개발을 시작한 개발자라면 데이터소스나 트랜잭션 매니저를 직접 등록한 적이 없을 것이다. 이 부분을 잠시 살펴보자. 데이터소스와 트랜잭션 매니저를 스프링 빈으로 직접 등록 @Bean DataSource dataSource() { return new DriverManagerDataSource(URL, USERNAME, PASSWORD); } @Bean PlatformTransactionManager transactionManager() { return new DataSourceTransactionManager(dataSource()); } 기존에는..

트랜잭션 문제 해결 - 트랜잭션 AOP 이해 지금까지 트랜잭션을 편리하게 처리하기 위해서 트랜잭션 추상화도 도입하고, 추가로 반복적인 트랜잭션 로직을 해결하기 위해 트랜잭션 템플릿도 도입했다. 트랜잭션 템플릿 덕분에 트랜잭션을 처리하는 반복 코드는 해결할 수 있었다. 하지만 서비스 계층에 순수한 비즈니스 로직만 남긴다는 목표는 아직 달성하지 못했다. 이럴 때 스프링 AOP를 통해 프록시를 도입하면 문제를 깔끔하게 해결할 수 있다. 참고 스프링 AOP와 프록시에 대해서 지금은 자세히 이해하지 못해도 괜찮다. 지금은 @Transactional을 사용하면 스프링이 AOP를 사용해서 트랜잭션을 편리하게 처리해 준다 정도로 이해해도 된다. 스프링 AOP와 프록시에 대한 자세한 내용은 스프링 핵심 원리 - 고급편을..

트랜잭션 템플릿 트랜잭션을 사용하는 로직을 살펴보면 다음과 같은 패턴이 반복되는 것을 확인할 수 있다. 트랜잭션 사용 코드 //트랜잭션 시작 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 MemberRepositoryV3 package hello.jdbc.repository; import hello.jdbc.domain.Member; import lombok.extern.slf4j.Slf4j; import org.springframework.jdbc.datasource.DataSourceUtils; import org.springframework.jdbc.support.JdbcUtils; import javax.sql.DataSource; import java.sql.*; import java.util.NoSuchElementException; /** * 트랜잭션 - 트랜잭션 매니저 * DataSourceUtils.getConnection() * ..