Exception ou RuntimeException pour les exceptions personnalisées en entreprise ? Pourquoi ?

Cet article participe au "Golden Stone Project. Share 60,000 cash prize"

séquence

Aujourd'hui, j'ai discuté avec mes collègues des anomalies, et je les organise ici

 目前公司中使用的 自定义异常是 extend RuntimeException 

exception d'héritage

Héritons-nous des exceptions dans le développement commercial pour étendre RuntimeException ou Exception ?

Je pensais que ce devait être une RuntimeException, mais pourquoi ? Vous ne pouvez pas choisir Exception ?

La différence entre RuntimeException et Exception

Avant d'en parler, nous devons déterminer quels sont nos besoins

besoin

L'exigence est de personnaliser une exception utilisée dans une entreprise

Après avoir déterminé les besoins, nous analyserons

Ici, nous savons que notre développement commercial est essentiellement une exception d'exécution, alors utilisez RuntimeException

Il y a une question ici. Lorsque nous effectuons habituellement des opérations IO, nous devenons souvent populaires et nous laissons lancer ou essayer d'attraper. Quel attribut cela fait-il ?

Regardez d'abord un morceau de code

Mais cette exception est due au fait que l'exception levée par la méthode createNewFile n'a rien à voir avec le fait qu'il s'agisse ou non d'une RuntimeException.

public boolean createNewFile() throws IOException {
    SecurityManager security = System.getSecurityManager();
    if (security != null) security.checkWrite(path);
    if (isInvalid()) {
        throw new IOException("Invalid file path");
    }
    return fs.createFileExclusively(path);
}
复制代码

C'est lié, non-RuntimeException nécessite des lancements ou des tentatives de capture, mais ce n'est pas automatique, c'est ce que les développeurs doivent faire lors de l'écriture de code, ce qui signifie que cette exception doit être vérifiée

Et d'autres références à noter Une partie de la page 434 du livre Principes des langages de programmation

Cette pièce laisse une question sur laquelle utiliser dans l'entreprise.

En quoi est-il différent des autres codes RuntimeException ?

Il n'y a pas de différence, c'est-à-dire que l'un hérite de RuntimeException, l'autre hérite d'Exception et rien d'autre

Intercepter les exceptions dans les transactions

我们到这 知道了继承异常应该用RuntimeException，但是我们应该知道 阿里规约手册 中有这么一段

1、让检查异常也回滚：你就需要在整个方法前加上@Transactional(rollbackFor=Exception.class)

2、让非检查异常不回滚：
需要加入@Transactional(notRollbackFor=RunTimeException.class)

3、不需要事务管理（or 日志丢失）
需要加入@Transactional(propagation=Propagation.NOT_SUPPORTED)

为什么？

Exception类下面除了runtimeException还有SQLException和ioException

如果方法没有抛出runtimeException 而是抛出 SQLException和ioException那么事务是不会回滚的

那么这就结束了吗？在我们编码过程中，如果方法要抛出一些可检查异常时是需要throws进行显式指定异常类的

那么问题来了，我们都知道方法签名中默认是throws RuntimeException,已知SqlException不是RuntimeException的子类

小总结

@Transactional(notRollbackFor=RunTimeException.class) 是因为抛弃了 IO异常和 SQL异常等情况，所以 我们 应该用 Transactional(rollbackFor=Exception.class)

为什么 不是 rollbackFor = Throwable.class 呢

Il n'est pas nécessaire de le spécifier explicitement  rollbackFor = Throwable.class , car spring annulera par défaut la transaction si cela se produit 错误. **

À l'origine, à l'exception de non-RuntimeException, d'autres sont déjà dans la gestion des transactions

Dans sa configuration par défaut, le code d'infrastructure de transaction de Spring Framework marque uniquement les transactions pour la restauration d'exécution avec des exceptions non contrôlées, c'est-à-dire des exceptions levées qui sont des instances ou des sous-classes de RuntimeException.  (Les erreurs entraîneront également - par défaut, une annulation) . Les exceptions vérifiées levées à partir des méthodes transactionnelles ne provoquent pas de restauration dans la configuration par défaut. **

ou voir DefaultTransactionAttribute

public boolean rollbackOn(Throwable ex) { 
        return (ex instanceof RuntimeException || ex instanceof Error); 
}
复制代码

Emplacement spécifique docs.spring.io/spring-fram…

Pour résumer, @Transactional(rollbackFor=Exception.class) doit être utilisé pour les transactions

Quels sont les scénarios d'application d'autres middlewares pour les exceptions et pourquoi ?

Regardez d'abord les nacos

//检查 异常
public class NacosException extends Exception {
}
复制代码

lors de l'utilisation

Il y a des lancers et essayer d'attraper

Alors, qu'est-ce qui lance l'exception Nacos ?

private <T extends Response> T requestToServer(AbstractNamingRequest request, Class<T> responseClass)
        throws NacosException {
    try {
        xxx
    } catch (Exception e) {
        throw new NacosException(NacosException.SERVER_ERROR, "Request nacos server failed: ", e);
    }
    throw new NacosException(NacosException.SERVER_ERROR, "Server return invalid response");
}
复制代码

fuséemq

Examinez d'abord une exception d'exécution

运行时异常
public class AclException extends RuntimeException {
}
复制代码

utilisation

public static void verify(String netaddress, int index) {
    if (!AclUtils.isScope(netaddress, index)) {
        //运行的时候 发生异常
        throw new AclException(String.format("Netaddress examine scope Exception netaddress is %s", netaddress));
    }
}
复制代码

Regardez une autre exception vérifiée

public class MQClientException extends Exception {
}
复制代码

throws MQClientException, RemotingException, MQBrokerException
复制代码

utilisation

public TransactionSendResult sendMessageInTransaction(final Message msg,
    final LocalTransactionExecuter localTransactionExecuter, final Object arg)
    throws MQClientException {
    TransactionListener transactionListener = getCheckListener();
    if (null == localTransactionExecuter && null == transactionListener) {
        //如果为空 client 异常
        throw new MQClientException("tranExecutor is null", null);
    }
 }
复制代码

Résumer

La plupart des middleware sont des échecs de connexion client, des délais d'attente de connexion à distance et des exceptions côté serveur, qui sont des exceptions lors de l'inspection, vous devez donc étendre Exception

mais

1. Pendant le développement commercial, la plupart des jugements sont vides et il est recommandé que RunntimeException soit une exception d'exécution.
2. Les exceptions doivent être levées tout le temps pendant l'inspection, et RunntimeException est recommandé du point de vue de la propreté du code

Résumer

1. L'utilisation de connexions à distance / les vérifications d'utilisation anormales sont anormales, de sorte que l'autre extrémité peut ressentir l'anomalie
2. Le code dans l'entreprise utilise des exceptions d'exécution

Je recommande toujours d'utiliser extend RuntimeException for business , et le reste doit être sélectionné en fonction du scénario métier

pense

 ok 那你说 远程连接使用 检查时异常，那feign 属于远程rpc，他的异常就必须是 检查时异常么？为什么？