rejectValue() , reject() 를 사용하면 FieldError , ObjectError를 직접 생성하지 않고, 깔끔하게 검증 오류를 다룰 수 있다.
rejectValue() 는 FieldError 이고 reject() 는 ObjectError이다.
rejectValue(@Nullable String field, String errorCode, @Nullable Object[] errorArgs, @Nullable String defaultMessage);
- field : 오류 필드명
- errorCode : 오류 코드(이 오류 코드는 메시지에 등록된 코드가 아니다. 뒤에서 설명할 messageResolver를 위한 오류 코드이다.)
- errorArgs : 오류 메시지에서 {0} 을 치환하기 위한 값
- defaultMessage : 오류 메시지를 찾을 수 없을 때 사용하는 기본 메시지
bindingResult.addError(new FieldError("memberVO", "memId", memberVO.getMemId(), false, new String[] {"required.item.itemName"}, null, "* 아이디는 필수 항목."));
저렇게 길었던 코드들을
Controller
위와 같이 저렇게 바꿔줄 수 있다.
bindingResult는 이미 objectName을 알고 있다.
errors.properties
반드시 memberVO 처럼 오브젝트 명. memId 처럼 필드 명 을 명시해주어야 작동한다.
또, reqired나 range만 작성하면서 단순하게 만들어줄 수도 있다. 범용성을 높여주는 것이다.
컨트롤러에서 "required"나 "range" 자리와 같이
errorCode에 해당하는 자리에 errors.properties에 있는 앞글자만 따와주었는데, 왜 이렇게만 해도 동작이 될까?
Controller
그리고 required는 *need required인데 왜 required.memberVO.memId에 있는 *Product name is required가 될까?
Level1부터 찾고, 만약 Level1과 같은 디테일 메시지가 없으면 Level2 이렇게 실행되는 것이다.
Level3에 있는 java.lang.String과 같이 문자열 오류도 표기할 수 있다.
typeMismatch
또한 스프링에서 메시지 코드가 없을 경우 스프링이 생성한 기본 메시지가 실행되는데,
이때 typeMismatch를 사용하면 된다. 이는 스프링이 직접 만든 에러표현이다.
errors.properties에 typeMismatch = *type error를 추가하면 긴 코드가 나오지 않고 설정한 에러구문이 나온걸 볼 수 있다.
'✨ Back-end > etc' 카테고리의 다른 글
[Spring] 검증(validation) - 6 Bean Validation @어노테이션 (0) | 2023.10.10 |
---|---|
[Spring] 검증(Validation) -5 Validator 인터페이스 (1) | 2023.10.06 |
[Spring] 검증(Validation) -3 , FieldError와 properties값 가져오기 (0) | 2023.09.27 |
[Spring] 검증(Validation) -2 BindingResult (0) | 2023.09.27 |
Axios 개념 (0) | 2023.09.26 |
댓글