java - Lorsque SpringMVC intègre le validateur Hibernate pour vérifier les paramètres, pourquoi ne lève-t-il pas directement une exception ?

Question

Bonjour à tous, j'ai une question

1. Environnement

spring 4.3.7
hibernate-validator-5.4.1

2. La configuration est la suivante

    <bean id="messageSource"
        class="org.springframework.context.support.ReloadableResourceBundleMessageSource" name="messageSource">
        <property name="basenames">
            <list>
                <value>classpath:messages/messages</value>
                <value>classpath:messages/ValidationMessages</value>
            </list>
        </property>
        <property name="useCodeAsDefaultMessage" value="false" />
        <property name="defaultEncoding" value="UTF-8" />
        <property name="cacheSeconds" value="60" />
    </bean>

    <bean id="validator" class="org.springframework.validation.beanvalidation.LocalValidatorFactoryBean">
        <property name="providerClass" value="org.hibernate.validator.HibernateValidator"/>
        <property name="validationMessageSource" ref="messageSource"/>
    </bean>
    
    
    <mvc:annotation-driven validator="validator" />

3.bean et contrôleur

public class UserRequest {
    
    @NotBlank(message = "{login.valid.username.notnull}")
    private String username;
    
    @NotBlank(message = "{login.valid.password.notnull}")
    private String password;

    public String getUsername() {
        return username;
    }

    public void setUsername(String username) {
        this.username = username;
    }

    public String getPassword() {
        return password;
    }

    public void setPassword(String password) {
        this.password = password;
    }

}

    @RequestMapping(value = "/login", method = RequestMethod.POST)
    @ResponseBody
    public Object login(@Valid @RequestBody UserRequest ur, BindingResult result, HttpServletRequest request) {
        
        log.debug("login");
        
        if(result.hasErrors()) {  
            return result.getAllErrors().get(0);  
        } 
        
        ……
    }

Question :
Pourquoi devons-nous utiliser result.hasErrors() pour afficher le jugement dans le code ?
N'est-il pas plus raisonnable de vérifier que les champs de UserRequest ne répondent pas à la définition et de simplement lancer une exception directement ?

Answer 1

Question :
Pourquoi devons-nous utiliser result.hasErrors() pour afficher le jugement dans le code ?
N'est-il pas plus raisonnable de vérifier que les champs de UserRequest ne répondent pas à la définition et de simplement lancer une exception directement ?

Par exemple, lorsqu'une exception de paramètre se produit, ce que nous renvoyons au front-end est le nom du paramètre spécifique et la description de l'exception, et non toutes les informations sur l'exception fournies par Spring. Si Spring lève automatiquement une exception, alors c'est difficile pour vous. pour contrôler les informations renvoyées.

@PostMapping(UriView.REST_KNOWLEDGE_POINTS)
@ResponseBody
public Result createKnowledgePoint(@Valid KnowledgePoint knowledgePoint, BindingResult bindingResult) {
    // 如有参数错误，则返回错误信息给客户端
    if (bindingResult.hasErrors()) {
        return Result.fail(CommonUtils.getBindingMessage(bindingResult));
    }

    knowledgePoint.setKnowledgePointId(CommonUtils.uuid());
    knowledgePoint.setName(knowledgePoint.getName().trim());
    mapper.createKnowledgePoint(knowledgePoint);

    return Result.ok("", knowledgePoint);
}

/**
 * BindingResult 中的错误信息很多，对用户不够友好，使用 getBindingMessage()
 * 提取对用户阅读友好的定义验证规则 message。
 *
 * @param result 验证的结果对象
 * @return 验证规则 message
 */
public static String getBindingMessage(BindingResult result) {
    StringBuffer sb = new StringBuffer();

    for (FieldError error : result.getFieldErrors()) {
        // sb.append(error.getField() + " : " + error.getDefaultMessage() + "\n");
        sb.append(error.getDefaultMessage() + "\n");
    }

    return sb.toString();
}

Answer 2

Vous réfléchissez simplement au pourquoi de votre scénario d'application. Un cadre consiste davantage à considérer ce qui est le plus raisonnable la plupart du temps.

La plupart des validations de données clients ne doivent pas être considérées comme des « anomalies », mais des erreurs que les utilisateurs sont autorisés à commettre sans le savoir.