오류 코드와 메시지 처리

오류 코드와 메시지 처리 by 메시지 파일 처리 

FieldError와 ObjectError의 생성자에는 codes와 argument를 제공합니다. 이 파라미터는 오류 발생시 오류 코드로 메시지를 찾기 위해 사용됩니다.

오류 메시지를 파일 한군데에 모으고 오류코드를 이용해서 앞서 배운 메시지 처리를 응용해 오류 메시지를 생성해보겠습니다.

errors 메시지 파일 생성

errors.properties

required.item.itemName=상품 이름은 필수입니다.
range.item.price=가격은 {0} ~ {1} 까지 허용합니다.
max.item.quantity=수량은 최대 {0} 까지 허용합니다.
totalPriceMin=가격 * 수량의 합은 {0}원 이상이어야 합니다. 현재 값 = {1}

application.properties에 등록

spring.messages.basename=messages,errors

Controller 수정 - Field 검증 

// 검증 로직 - 이름
if(!StringUtils.hasText(item.getItemName()))
{
    bindingResult.addError(new FieldError("item","itemName",item.getItemName(),false,
            new String[]{"required.item.itemName"},null,null));
}

// 검증 로직 - 가격
if(item.getPrice()==null || item.getPrice()<1000 || item.getPrice() > 1000000)
{
    bindingResult.addError(new FieldError("item","itemName",item.getPrice(),false,
            new String[]{"range.item.price"},new Object[]{1000,100000},null));
}

// 검증 로직 - 수량
if(item.getQuantity() == null || item.getQuantity() >= 9999)
{
    bindingResult.addError(new FieldError("item","quantity",item.getQuantity(),false,
            new String[]{"max.item.quantity"},new Object[]{9999},null));
}

추가 파라미터인 codes와 argument를 이용해 오류 메시지를 등록할 수 있습니다.

• codes : required.item.itemName을 사용해서 메시지 코드를 지정했습니다. 
  • 메시지 코드는 하나가 아니라 배열로 여러값을 전달할 수 있는데, 순서대로 매칭해서 처음 매칭되는 메시지가 사용됩니다.
• argument : Object[]{1000,10000}을 사용해서 코드의 {0},{1}로 치환할 값을 전달하는 역할을 합니다.

Controller 수정 - 복합 Field 검증

if(item.getPrice() != null && item.getItemName()!=null)
        {
            int resultPrice = item.getPrice() * item.getQuantity();
            if(resultPrice<10000)
            {
                bindingResult.addError(new ObjectError("item",new String[]{"totalPriceMin"},new Object[]{10000,resultPrice},null));
            }
        }

---

오류 코드와 메시지 처리 by reject(), rejectValue()

이번에는 bindingResult에 FieldError나 ObjectError를 addError하지 않고 좀 더 자동화된 방법을 사용해 보겠습니다.

• Bindingresult는 addError뿐만 아니라 rejectValue() (FieldError의 경우 사용), reject() (ObjectError의 경우 사용) 메소드를 제공합니다.
• 이 rejectValue(), reject() 메소드를 사용하면 FieldError나 ObjectError를 직접 생성하지 않고 깔끔하게 검증 오류를 다룰 수 있습니다.

if(!StringUtils.hasText(item.getItemName()))
{
    bindingResult.rejectValue("itemName","required", null, null);
}

// 검증 로직 - 가격
if(item.getPrice()==null || item.getPrice()< 1000 || item.getPrice() > 1000000)
{
    bindingResult.rejectValue("price","range", new Object[]{1000,1000000}, null );
}

// 검증 로직 - 수량
if(item.getQuantity() == null || item.getQuantity() >= 9999)
{
    bindingResult.rejectValue("quantity","max", new Object[]{9999},null);
}

if(item.getPrice() != null && item.getItemName()!=null)
{
    int resultPrice = item.getPrice() * item.getQuantity();
    if(resultPrice<10000)
    {
        bindingResult.reject("totalPriceMin",new Object[]{10000,resultPrice},null);
    }
}

errors.properties에 있는 메시지 코드를 직접 입력하지 않았는데 어떻게 된 것일까요??

 

우선 rejectValue()는 파라미터로 네가지를 입력받습니다.

1) field  : 오류 필드명

2) errorCode : 오류 코드 ( 메시지 파일에 등록된 코드가 아닌 messageResolver를 위한 오류 코드로 뒤에서 다루도록 하겠습니다. )

3) errorArgs : 오류 메시지에서 {}을 치환하기 위한 값 

4) defaultMessage : 오류 메시지를 찾을 수 없을 때 사용하는 기본 메시지

 

BindingResult는 어떤 객체를 대상으로 검증하는지 이미 @ModelAttribute를 통해 알고 있습니다. 따라서 사실 objectName을 입력받지 않아도 BindingResult는 알고 있습니다.

---

reject, rejectValue()는 간단하게 말하면 이렇게 동작합니다.

FieldError나 ObjectError를 직접 다룰 때는 오류코드를 required.item.itemName처럼 직접 모두 입력했었습니다. 그런데 rejectValue()를 사용하고 나서부터는 오류 코드를 required처럼 간단하게 입력했는데도 오류 메시지를 잘 찾아서 출력했습니다.

이 부분은 사실 MessageCodesResolver가 동작하여 메시지 코드를 생성한 덕분에 가능한 일입니다.

 

1. objectName과(@ModelAttribute을 통해 이미 알고 있음) 입력받은 itemName, errorCode를 통해 MessageResolver에서 메시지 코드를 생성합니다.

 

2. 생성된 메시지 코드 순서대로 rejectValue()의 경우 FieldError를, reject()의 경우에는 ObjectError를 만들어 줍니다.

 

3. 타임리프 뷰템플릿에서는 th:errors를 이용해 오류가 있을 경우 생성된 오류 메시지 코드를 순서대로 돌아가면서 메시지 코드에 대한 메시지를 찾아 출력합니다. 없다면 디폴트 메시지 출력.

---

우선 오류 코드를 어떻게 만들 수 있는지 간단하게 알아보고, MessageCodesResolver 동작 방식을 알아보도록 하겠습니다.

 

오류 코드를 만들 때는

#Level 1
required.item.itemName = 상품 이름은 필수입니다.

#Level 2
required = 필수 값입니다. 

이렇게 객체명과 필드명을 조합해 세밀한 메시지 코드를 만들 수도 있고, 간단하게 객체명만 가지고 만들 수도 있습니다.

 

❗️ 우선순위는 객체명과 필드명을 조합한 세밀한 메시지 코드가 더 높은 우선순위를 가집니다.

 

사실 스프링은 MessageCodesResolver라는 것으로 이렇게 메시지 코드를 만들어주는 기능을 지원합니다. 이제 MessageCodesResolver에 대해 알아보겠습니다.

---

MessageCodesResolver

MessageCodesResolver로 ObjectError 만들기 

• 검증 오류 코드로 메시지 코드들을 생성합니다.
• MessageCodesResolver는 인터페이스이고 DefaultMessageCodesResolver가 기본 구현체.
• DefaultMessageCodesResolver는 errorCode와 objectName을 통해 메시지 코드를 생성합니다.

DefaultMessageCodesResolver의 ObjectError 생성 규칙

객체 오류의 경우 다음 순서로 2가지 생성
1 / code + "." + object name
2/  code

MessageCodesResolver로 FieldError 만들기 

• DefaultMessageCodesResolver는 errorCode와 objectName과 fieldName과 field type을 통해 메시지 코드 4개를 생성합니다.

필드 오류의 경우 다음 순서로4가지 메시지 코드 생성합니다.

1.: code + "." + object name + "." + field
2.: code + "." + field
3.: code + "." + field type
4.: code

예를 들어 itemName 의 경우 required 검증 오류 메시지가 발생하면 다음 코드 순서대로 메시지가 생성된다.

1. required.item.itemName 2. required.itemName 3. required.java.lang.String  4. required

그리고 이렇게 생성된 메시지 코드를 기반으로 순서대로 MessageSource에서 메시지를 찾습니다.

 

이 기능을 통해 스프링이 직접 만든 오류 메시지도 처리할 수 있습니다.

타입 오류 발생 시 스프링은 BindingResult에 타입 오류를 FieldError에 자동으로 담아 준다고 했었죠.

로그를 확인해보면

codes를 살펴보면 스프링은 타입오류 발생 시 typeMistmatch라는 오류 코드를 사용하는 것을 확인할 수 있습니다.

이 오류 코드가 MessagesCodesResolver를 통하면서 

typeMismatch.item.price,  typeMismatch.price,   typeMismatch.java.lang.Integer,   typeMismatch

4가지 메시지 코드가 생성되었습니다.

 

errors.properties에 메시지 코드가 없기 때문에 이렇게 defaultMessage로 Failed to ~... 메시지가 출력되는 것인데요.

 

errors.properties에 이렇게 추가해주면 ( 4개 다 안해도 됨 )

#추가
typeMismatch.item.price=숫자를 입력해주세요.
typeMismatch.price=숫자만 입력해주세요.
typeMismatch.java.lang.Integer= 타입 오류입니다.
typeMismatch= 타입이 잘못되었습니다.

 

타입 오류에 대한 기본 메시지도 변경할 수 있습니다.

---

Validator 분리

컨트롤러에 구현된 복잡한 검증로직을 Validator를 사용해서 분리해보겠습니다.

 

Validator는 스프링이 제공하는 검증기이며, 인터페이스로 구현되어있습니다.

public interface Validator {

   /**
    * Can this {@link Validator} {@link #validate(Object, Errors) validate}
    * instances of the supplied {@code clazz}?
    * <p>This method is <i>typically</i> implemented like so:
    * <pre class="code">return Foo.class.isAssignableFrom(clazz);</pre>
    * (Where {@code Foo} is the class (or superclass) of the actual
    * object instance that is to be {@link #validate(Object, Errors) validated}.)
    * @param clazz the {@link Class} that this {@link Validator} is
    * being asked if it can {@link #validate(Object, Errors) validate}
    * @return {@code true} if this {@link Validator} can indeed
    * {@link #validate(Object, Errors) validate} instances of the
    * supplied {@code clazz}
    */
   boolean supports(Class<?> clazz);

   /**
    * Validate the supplied {@code target} object, which must be
    * of a {@link Class} for which the {@link #supports(Class)} method
    * typically has (or would) return {@code true}.
    * <p>The supplied {@link Errors errors} instance can be used to report
    * any resulting validation errors.
    * @param target the object that is to be validated
    * @param errors contextual state about the validation process
    * @see ValidationUtils
    */
   void validate(Object target, Errors errors);

}

• supports(Class<?> clazz) :  해당 검증기를 지원하는지 여부 
• validate(Object target, Errors errors) : "검증 대상 객체"와 오류를 담을 BindingResult

이 Validator를 이용해 ItemValidator를 만들고 ItemValidator에 검증로직을 구현해서 Controller에서 ItemValidator를 가져다가 쓰도록 하면 컨트롤러 코드가 훨씬 깔끔해지고 유지보수가 편리해집니다. 한번 구현해보겠습니다.

 

ItemValidator

@Component
public class ItemValidator implements Validator {

    @Override
    public boolean supports(Class<?> clazz)
    {
        return Item.class.isAssignableFrom(clazz);
        // item == clazz
        // item == subItem
    }

    @Override
    public void validate(Object target, Errors errors)
    {
        Item item = (Item) target;

        ValidationUtils.rejectIfEmptyOrWhitespace(errors,"itemName", "required");

        if(item.getPrice()==null || item.getPrice() < 1000 || item.getPrice() > 1000000)
        {
            errors.rejectValue("price","range",new Object[]{1000,1000000},null);
        }

        if(item.getQuantity()==null || item.getQuantity() > 10000 || item.getQuantity() < 1 )
        {
            errors.rejectValue("quantity","max",new Object[]{9999},null);
        }

        if(item.getPrice() != null && item.getQuantity() != null)
        {
            int resultPrice = item.getPrice() * item.getQuantity();
            if(resultPrice<10000)
            {

                errors.reject("totalPriceMin",new Object[]{10000,resultPrice},null);
            }
        }
    }
}

검증로직을 ItemValidator에서 Validator 인터페이스를 구현했습니다.

 

private final ItemValidator itemValidator;

@PostMapping("/add")
public String addItemV5(@ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes)
{
//        boolean supports = itemValidator.supports(item.getClass());
//        System.out.println("supports = " + supports);

    itemValidator.validate(item,bindingResult);
    if(bindingResult.hasErrors())
    {
        log.info("errors={}",bindingResult);
        return "validation/v2/addForm";
    }

    Item savedItem = itemRepository.save(item);
    redirectAttributes.addAttribute("status",true);
    redirectAttributes.addAttribute("itemId",savedItem.getId());
    return "redirect:/validation/v2/items/{itemId}";
}

이제 컨트롤러에서 스프링 컨테이너에 등록한 ItemValidor를 사용하도록 의존관계를 주입해주고, itemValidator의 validate를 통해 오류 발생시 bindingResult에 담아주었습니다.

---

Validator 분리2

사실 스프링이 제공하는 Validator 인터페이스를 사용해서 검증기를 만들면 추가적인 도움을 받을 수 있습니다.

어떤 도움을 받을 수 있는지 알아보겠습니다.

@InitBinder
public void init(WebDataBinder dataBinder)
{
    log.info("init binder {}", dataBinder);
    dataBinder.addValidators(itemValidator);
}

WebDataBinder는 구현한 검증기(Validator)를 담을 수 있는 기능을 제공합니다.

이렇게 WebDataBinder에 검증기를 추가하고 @InitBinder를 사용하면 컨트롤러가 호출되면 WebDataBinder에 구현한 Validator를 넣고 사용할 수 있습니다.

@PostMapping("/add")
public String addItemV6(@Validated @ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes)
{
    if(bindingResult.hasErrors())
    {
        log.info("errors={}",bindingResult);
        return "validation/v2/addForm";
    }

    Item savedItem = itemRepository.save(item);
    redirectAttributes.addAttribute("status",true);
    redirectAttributes.addAttribute("itemId",savedItem.getId());
    return "redirect:/validation/v2/items/{itemId}";
}

@Validated는 검증기를 실행하라는 어노테이션 인데 이 어노테이션이 붙으면 앞서 WebDataBinder에 등록한 검증기를 찾아서 실행해줍니다. 그런데 여러 검증기를 등록한다면 그중에 어떤 검증기가 실행되어야 할지 구분이 필요하겠죠. 이 때 supports()가 사용됩니다.

 

여기서는 supports(Item.class)가 호출되고, 결과가 true 이므로 ItemValidator의 validate()가 호출됩니다 -> 검증 로직에 실패하면 bindingResult에 오류 메시지를 담습니다. ( 자동화 )

 

 

+ Validator 글로벌설정하기

애플리케이션에 등록

@SpringBootApplication
public class ItemServiceApplication implements WebMvcConfigurer {

   public static void main(String[] args) {
      SpringApplication.run(ItemServiceApplication.class, args);
   }

   @Override
   public Validator getValidator()
   {
      return new ItemValidator();
   }
}

@PostMapping("/add")
public String addItemV6(@Validated @ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes)
{
    if(bindingResult.hasErrors())
    {
        log.info("errors={}",bindingResult);
        return "validation/v2/addForm";
    }

    Item savedItem = itemRepository.save(item);
    redirectAttributes.addAttribute("status",true);
    redirectAttributes.addAttribute("itemId",savedItem.getId());
    return "redirect:/validation/v2/items/{itemId}";
}

이렇게 애플리케이션에 등록하면 모든 컨트롤러에 적용할 수 있습니다.

하지만 글로벌하게 설정하는 경우는 거의 없기 때문에 컨트롤러 레벨에서 @InitBinder를 사용해 컨트롤러 호출시에 WebDataBinder에 검증기를 담아 사용하겠습니다.