코드 땜장이

동기와 비동기, 블로킹과 논블로킹을 호출 흐름으로 구분하기 빠른 답 동기와 비동기는 결과를 호출 흐름 안에서 기다릴지, 나중에 별도 흐름으로 받을지의 차이다. 블로킹과 논블로킹은 호출한 스레드가 멈춰서 기다리는지, 제어권을 돌려받아 다음 일을 할 수 있는지의 차이다. 비동기 API를 써도 결과를 바로 get() 이나 join() 으로 기다리면 다시 블로킹 구간이 생긴다. Spring @Async 는 프록시와 Executor 위에서 동작하므로 내부 호출, 예외, 트랜잭션, 스레드풀 포화 상태를 함께 봐야 한다. 목차 한눈에 비교 시간 흐름으로 이해하기 왜 헷갈릴까 동기와 블로킹이 항상 같은 말은 아니다 코드와 출력으로 보는 실행 시점 값, 상태, 오류의 의미 현재 기준 버전과 마이그레이션 포인트 Spring Async 설정과 반환 타입 내부 호출, 예외, 트랜잭션 함정 디버깅과 운영 로그 한눈에 비교 관계 기준 동기와 비동기는 호출자와 작업 결과가 같은 흐름에 묶이는지로 나뉜다. 제어권 기준 블로킹과 논블로킹은 호출 후 현재 스레드가 대기 상태에 들어가는지로 나뉜다. 값 기준 동기 호출은 대개 T 또는 예외를 돌려주고, 비동기 호출은 CompletableFuture<T> 처럼 나중의 완료 상태를 나타내는 핸들을 돌려준다. 오류 기준 동기 오류는 호출 지점의 try-catch 에서 보이고, 비동기 오류는 완료 핸들러, get() , join() 같은 관찰 지점에서 보인다. Spring 기준 @Async 는 호출자 흐름을 먼저 반환시킬 수 있지만, 작업 스레드 안에서 JDBC, 파일, 외부 API를 호출하면 그 스레드는 여전히 블로킹될 수 있다. 시간 흐름으로 이해하기 호출 시작 호출자는 작업을 요청하고 결과가 필요한지, 나중에 받아도 되는지를 정한다. → 제어권 반환 동기 호출은 보통 결과가 나올 때까지 같은 흐름에 머물고, 비동기 호출은 완료 전에도 핸들을 돌려줄 수 있다. → 대기 구간 블로킹이면 현재 스레드가 멈추고, 논블로킹이...

자바 Checked Exception vs Unchecked Exception: 언제 복구하고 언제 코드부터 고칠까 빠른 답 Checked Exception 은 호출자가 재시도, 대체 경로, 사용자 안내 같은 대응을 선택할 수 있을 때 API 계약으로 드러내기 좋습니다. Unchecked Exception 은 잘못된 값, 잘못된 호출 순서, 깨진 상태처럼 코드 쪽 수정이 필요한 문제를 표현하는 경우가 많습니다. 둘 다 실제로는 실행 중에 발생합니다. 차이는 예외가 아니라 컴파일러가 처리 여부를 강제하느냐에 있습니다. Error 는 일반 애플리케이션 로직에서 복구 대상으로 보기보다, JVM이나 프로세스 수준의 심각한 문제로 보는 편이 가깝습니다. 목차 한눈에 비교 시간 흐름으로 이해하기 왜 둘 다 Exception인데 처리 방식은 다를까 Error와 Exception의 차이 실전 코드와 출력 예시로 보기 언제 무엇을 선택할까 커스텀 예외는 어디에 둘까 자주 틀리는 지점 한눈에 비교 검사 시점 Checked Exception 은 컴파일 시점에 처리 여부를 검사하고, Unchecked Exception 은 컴파일러가 강제하지 않습니다. 타입 계층 checked는 보통 Exception 하위 타입 중 RuntimeException 이 아닌 예외이고, unchecked는 RuntimeException 과 그 하위 타입입니다. 의미 checked는 외부 조건 때문에 작업이 실패할 수 있음을 드러내고, unchecked는 값 오류나 상태 불일치처럼 코드 전제가 깨졌음을 드러내는 경우가 많습니다. 호출자 책임 checked는 try-catch 또는 throws 로 책임을 명시해야 하고, unchecked는 필요할 때만 잡으면 됩니다. 관찰 가능한 결과 checked를 처리하지 않으면 컴파일 오류가 보이고, unchecked는 컴파일은 되지만 실행 중 스택 트레이스로 드러납니다. 복구 방향 checked는 재시도, 기본값 사용, 다른 자원 선택으로 이어지기 쉽...

스프링에서 @ControllerAdvice 를 언제 쓰고 어떻게 구성해야 할까 목차 왜 @ControllerAdvice 가 필요한가 @ControllerAdvice 와 @RestControllerAdvice 의 차이 스프링 MVC에서 전역 처리 로직은 어떻게 적용될까 적용 범위는 반드시 좁혀서 시작하는 것이 좋다 실전 예시: 공통 에러 응답과 전역 예외 처리기 @InitBinder 와 @ModelAttribute 는 언제 쓸까 에러 응답 설계에서 자주 놓치는 기준 기대대로 동작하지 않을 때 확인할 것 운영 가능한 구조로 정리하는 방법 빠른 답 여러 컨트롤러에서 반복되는 예외 처리 로직은 @ControllerAdvice로 모으는 것이 기본입니다. JSON 에러 응답이 목적이라면 보통 @RestControllerAdvice를 먼저 검토하면 됩니다. 적용 범위는 패키지나 애너테이션 기준으로 좁힐 수 있어 전역 남용을 막을 수 있습니다. 핸들러가 기대대로 동작하지 않으면 예외 타입, 우선순위, 응답 본문 생성 방식을 먼저 확인해야 합니다. 빠른 답 여러 컨트롤러에서 반복되는 예외 처리, 바인딩, 공통 모델 설정은 @ControllerAdvice 로 모으는 것이 기본입니다. REST API에서 JSON 에러 응답을 일관되게 내려야 한다면 보통 @RestControllerAdvice 를 먼저 선택합니다. 적용 범위는 basePackages , assignableTypes , annotations 로 좁혀야 전역 남용과 예상치 못한 충돌을 줄일 수 있습니다. 동작이 기대와 다르면 예외가 발생한 위치, 예외 타입 매칭, 여러 어드바이스의 우선순위와 응답 직렬화 방식을 먼저 확인해야 합니다. 컨트롤러 코드가 늘어나기 시작하면 비슷한 로직이 반복됩니다. 입력 검증 실패를 400으로 바꾸는 코드, 특정 비즈니스 예외를 404나 409로 바꾸는 코드, 날짜 문자열을 공통 형식으로 파싱하는 코드가 대표적입니다. 처음에는 각 컨트롤러에서 직접 처리해도 큰 문...