assert(false) vs RuntimeException?



我正在阅读XWalkUIClientInternal的源代码,我遇到了以下代码:

    switch(type) {
        case JAVASCRIPT_ALERT:
            return onJsAlert(view, url, message, result);
        case JAVASCRIPT_CONFIRM:
            return onJsConfirm(view, url, message, result);
        case JAVASCRIPT_PROMPT:
            return onJsPrompt(view, url, message, defaultValue, result);
        case JAVASCRIPT_BEFOREUNLOAD:
            // Reuse onJsConfirm to show the dialog.
            return onJsConfirm(view, url, message, result);
        default:
            break;
    }
    assert(false);
    return false;

我以前从未真正见过这种技术,也从未真正想过,但我想这本质上意味着"这是不可访问的代码,永远不应该发生",无论如何都会导致应用程序崩溃。尽管从技术上讲,你可以用投掷器做到这一点,只要它没有被抓住。

所以我的问题是,哪一个更好,为什么,assert(false)还是扔RuntimeException,或者可能扔Error

之间的最大差异

assert false;

(不需要括号,assert不是函数,而是语句。)和

throw new RuntimeException();

可以禁用断言。实际上,除非JVM是用-ea("启用断言")标志启动的,否则它在默认情况下是禁用的。如果启用断言,则assert false将无条件抛出从Error派生的AssertionError。但是,由于断言可以被禁用,因此存在两个问题,

  • 错误可能未被发现
  • 控制流分析需要在CCD_ 10之后有一个伪CCD_

因此,在上面的情况下,我当然会选择一个明确的(更简洁的)

throw new AssertionError("invalid type " + type);

而不是后面跟着伪CCD_ 12的CCD_。

如注释中所述,这是假设type是一个内部参数,无效值表示逻辑本身存在错误。如果它是一个输入参数,则应根据通常的规则对其进行验证,如果验证失败,则抛出IllegalArgumentException

遵循Oracle指南(使用断言编程),断言是为测试目的而设计的:

断言是Java编程语言中的一个语句使您能够测试您对程序的假设。例如如果编写一个计算粒子速度的方法可以断言计算出的速度小于光

每个断言都包含一个布尔表达式,您认为它将是当断言执行时为true。如果不是真的,系统将抛出错误。通过验证布尔表达式确实的确,该断言证实了您对你的程序,增加你对该程序免费的信心错误。

在您的示例中,开发人员假设代码从未到达assert语句。如果发生这种情况,assert(false)将抛出一个Error(因为它永远不会到达那里)。这是为了测试目的。因此,使用assert纯粹是为了测试目的。

最新更新