exception
Spring reactor 2.1.2 (netty 0.8.4) Mono.zip readTimeoutException 문제
Mono zip 각 Mono 처리 스레드를 병렬로 실행하고 이를 묶어서 사용할 수 있는게 Mono.zip이다. 근데 Mono zip에서 병렬로 실행되는 작업 중 하나가 empty 또는 error가 발생 되면 바로 error 또는 complete를 내뱉게 되어있다. 하지만 각 Mono 구독 작업에 error와 empty 발생 시 문제에 대해 fallback 처리를 해주면 에러가 발생하더라도 그 로직을 타게 되어있다. 하지만 2.1.2(netty 0.8.4) 버전을 사용하고 있을 때 호출 체인에서 첫 번째 요청의 실패 이후에 두 번째 요청이 정상적으로 이루어 지지 않아서 readTimeout이 발생되는 문제를 경험하였습니다. 이 문제를 해결하기 위해서 알아보던 중 2.1.2버전에 문제가 있는 것을 알게 되어..
생성한 Custom validation으로 에러메시지 출력하기
바로 직전 https://wedul.tistory.com/562?category=595982 에서 Custom validation을 만들어서 입력된 값에 validation을 체크하는 방법을 알아봤다.그럼 이 validation체크를 통해서 front에 상황에 맞는 에러를 보내줄 수 있도록 조치를 취해보자.우선 @valid 처리를 했었던 컨트롤러에서 에러 메시지를 수집해야한다. 1. ControllerSpring에서 Validation 작업을 진행할 시 validation에 문제가 발생하면 에러 내용을 묶어서 BindingResult로 처리할 수 있도록 제공해준다. 이를 사용하기 위해서 parameter로 BindingResult값을 추가해준다.1234567891011121314/** * 회원가입 * *..
Spring Validation을 이용해서 요청 검증처리
대게 개발을 진행할 때 front에서 validate를 체크하고 민감한 정보에 대해서는 한번더 체크를 진행하고 작업을 했었다. 하지만 클라이언트에서만 validation을 체크하게 되는 경우 브라우저에서 악의적인 행동에 대해서 대응하기 어려워질수 있기 때문에 백엔드에서도 Validation을 처리해야한다. 여기서 사용되는 @valid 어노테이션들을 알아보자. 1. DTO validation 선언 우선적으로 DTO에 각 속성에 필요한 @valid 옵션들을 추가한다.1234567891011121314151617181920212223242526272829303132package com.wedul.springboottest.rest.dto; import lombok.*; import javax.validatio..
규칙 65 - 예외를 무시하지마라.
사용하려고 하는 API의 설계자가 예외가 발생될 수 있다고 명시한 예외는 조심해야한다. 무시방법은 간단하게 호출하는 메서드를 빈 catch 블록이 붙은 try 문으로 감싸면, 예외를 무시할 수있다. 12345try { } catch (Exception ex) { }cs 빈 catch 블록은 예외를 선언한 목적으로 만들어진다.만약 이렇게 빈 catch 블록을 만들려고 하는 경우에는 적어도 왜 넘겼는지 주석을 달아주는 것이 좋다. 출처 : 조슈아 블로크, 『 Effective Java 2/E』, 이병준 옮김, 인사이트(2014.9.1), 규칙65
규칙 61 - 추상화 수준에 맞는 예외를 던져라
메서드가 하는 일과 관련성이 없는 예외가 메서드에서 발생하면 디버깅하기 어렵거나 관리하기 어려울 수 있다. 이는 추상화 수준이 낮은 곳에서 발생한 예외를 그대로 밖으로 전달하면 이런일이 발생한다. 이런 문제를 해결하기 위해서 상위계층에서는 하위계층에서 발생하는 예외를 반드시 받아서 상위 계층 추상화 수준에 맞는 예외로 바꿔서 던져야한다. 이를 예외 변환(exception translation)이라고 한다. 예를 들어 몇가지 사례를 살펴보자. 우선 AbstractSequentialList 클래스를 살펴보자. 이 클래스의 get 메서드의 명세를 보면 예외가 발생되었을 때 예외 변환을 해서 보내달라는 것을 확인할 수 있다. 12345678910111213141516 /** * Returns the elemen..
규칙 60 - 표준 예외를 사용해라
예외를 사용할 때 기존에 정의되어있는 표준예외를 사용하는 것이 좋다. 그 이유는 다음과 같다. - 배우기 쉽고 사용하기 편리한 API를 만들수 있으며 다른 프로그래머들도 친숙한 널리 퍼진 관습을 따르기 때문이다. - 잘모르는 예외가 없어 API 가독성을 높일수있다. - 예외클래스를 별도로 만들어서 클래스를 늘리지 않으면 프로그램의 메모리 요구량이 줄어들고 클래스를 로딩하는 시간도 줄어든다. 대표적인 표준 예외 예외용례lllegalArgumentExceptionnull이 아닌 인자값이 잘못되었을때llegalStateException객체 상태가 메서드 호출을 처리하기에 적절치 않을때NullPointerExceptionnull 값을 받으면 안 되는 인자에 null이 전달되었을 때IndexOutOfBoundsE..
규칙 58 복구가능 상태에는 점검지정 예외를 사용하고, 프로그래밍 오류에는 실행시점 예외를 이용하라.
자바에는 몇 가지에 throwable을 제공한다. 점검지정 예외 (checked error) 컴파일 시점에 예외가 발생하는 부분으로 컴파일 시에 에러를 처리하는 코드를 삽입하지 않으면 컴파일이 되지 않는다. 12345678910public void ioOperation(boolean isResourceAvailable) { try { if (!isResourceAvailable) { throw new IOException(); } } catch(IOException e) { // Handle caught exceptions. }} Colored by Color Scriptercs unchecked error 컴파일 시점에 체크되지 않는 에러 실생시점 예외(runtime exception)와 오류(erro..
java.lang.Error: Unresolved compilation problem
프로젝트를 git을 통해서 내려받고 실행시키고자 할때, 가끔 다음과 같은 오류가 발생할 때가 있다. java.lang.Error: Unresolved compilation problem 이 경우 해결방법은 2가지이다. 1. 프로젝트 clean2. tomcat clean, tomcat 디렉토리 clean