java - Pourquoi n'est-il pas recommandé de lancer RuntimeException directement dans le code?

Question

L'utilisation d'exceptions génériques telles que Error, RuntimeException, Throwable et Exception empêche les méthodes appelantes de gérer les vraies exceptions générées par le système différemment des erreurs générées par l'application.

Exemple de code non conforme

public void foo(String bar) throws Throwable {  // Noncompliant
  throw new RuntimeException("My Message");     // Noncompliant
}

Solution conforme

public void foo(String bar) {
  throw new MyOwnRuntimeException("My Message");
}

Answer 1

C'est facile à comprendre.
Utilisons une analogie simple. Maintenant, pour établir une connexion, le code doit être écrit comme ceci.用户不存在/密码错误... 这些错误类型, 如果你直接使用RuntimeException

throw new RuntimeException("user not found"); // 用户不存在
throw new RuntimeException("password not match"); // 密码错误

Détecter les exceptions

try {
    // ...逻辑
} catch(RuntimeException e) {
    if("user not found".equals(e.getMessage())) {
        // ...逻辑
    } else if("password not match".equals(e.getMessage())) {
        // ...逻辑
    }
}

---

Au contraire, l'exception personnalisée est implémentée comme suit :

throw new UserNotFoundException("user not found"); // 用户不存在
throw new PasswordNotMatchException("password not match"); // 密码错误

Détecter les exceptions

try {
    // ...逻辑
} catch(UserNotFoundException e) {
    // ...逻辑
} catch(PasswordNotMatchException e) {
    // ...逻辑
}

Il existe de nombreux inconvénients à juger la logique de gestion des exceptions via message. Par exemple, si message est dynamique, il ne sera pas traité avec précision

Bien sûr, nous pouvons également le faire. définir un type d'exception général, il sera plus précis de juger par le code métier, et cela réduira également la définition des types d'exception et réduira la redondance du code. Vous trouverez ci-dessous un morceau de code kotlin, qui est le. façon dont je l'utilise actuellement.message判断处理异常逻辑有很多弊端, 比如message是动态的, 那将无法准确的处理.
当然我们也可以定义一个通用的异常类型, 通过业务码去判断会更加准确, 同时也会减少异常类型的定义, 减少代码的冗余. 下面有一段kotlin

interface BizCode {

    val code: Int
    val msg: String
}

enum class BizCodes(override val code: Int, override val msg: String): BizCode {

    // ====================================================== //
    // 公共错误码 0 - 999                                      //
    // ====================================================== //
    /**
     * 未知错误.
     */
    C_0(0, "未知错误"),
    /**
     * HTTP Request 参数错误.
     */
    C_999(999, "HTTP Request 参数错误"),

    // ====================================================== //
    // client 错误码 1000 - 1999                               //
    // ====================================================== //
    /**
     * 未发现指定 client_id 客户端记录.
     */
    C_1000(1000, "未发现指定 client_id 客户端记录"),
    C_1001(1001, "client_secret 不匹配"),

    // ====================================================== //
    // user 错误码 2000 - 2999                                //
    // ====================================================== //

    /**
     * 未发现指定 email 的用户.
     */
    C_2000(2000, "未发现指定 email 的用户"),
    C_2011(2011, "password 不匹配"),

    //
    ;

    override fun toString(): String {
        return "[$code] $msg"
    }
}

class BizCodeException : RuntimeException {

    val bizCode: BizCode

    constructor(bizCode: BizCode) : super(bizCode.toString()) {
        this.bizCode = bizCode
    }

    constructor(bizCode: BizCode, e: Exception) : super(bizCode.toString(), e) {
        this.bizCode = bizCode
    }

    override fun fillInStackTrace() = this
}

Answer 2

L'explication est assez claire, ce qui la rend facile à capturer et à traiter

Answer 3

Les noms d'exception doivent être significatifs, les noms RuntimeException n'ont aucun sens

Answer 4

Si vous lancez directement une exception, Nginx écrasera votre message défini et vous ne pourrez pas voir les informations spécifiques.
L'approche recommandée consiste à définir vous-même une exception et à hériter de RuntimeException. Cela vous aidera à connaître votre exception et facilitera la recherche de problèmes.

Answer 5

Les exceptions d'exécution n'ont pas besoin d'être interceptées