java – assert(false)vs RuntimeException？

发布时间：2020-12-15 00:56:14 所属栏目：Java 来源：网络整理

导读：我正在阅读 XWalkUIClientInternal的源代码,我遇到了以下代码： switch(type) { case JAVASCRIPT_ALERT: return onJsAlert(view,url,message,result); case JAVASCRIPT_CONFIRM: return onJsConfirm(view,result); case JAVASCRIPT_PROMPT: return onJsPromp

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

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

我从来没有真正看过这种技术,也没有真正考虑过它,但我想这实际上意味着“这是无法访问的代码,不应该永远发生”,无论如何都会崩溃应用程序.虽然技术上你可以用Throwable做到这一点,只要它没有被抓住.

所以我的问题是,哪一个更好,为什么,断言(假)或抛出RuntimeException,或者可能是一个错误？

解决方法

最大的区别

assert false;

(不需要括号,断言不是函数,而是声明.)和

throw new RuntimeException();

是断言可以被禁用.实际上,默认情况下它被禁用,除非JVM以-ea(“enable assertions”)标志启动.如果启用了断言,则断言false将无条件地抛出一个源自Error的AssertionError.但由于断言可以被禁用,因此有两个问题,

>错误可能无法检测到
>控制流分析需要在断言之后使用伪返回语句(这主要是杂乱的).

因此,在上述情况下,我肯定会明确(更简洁)

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

而不是断言后跟虚拟回报.

正如评论中所提到的,这假设类型是内部参数,无效值表示逻辑本身存在错误.如果它是输入参数,则应根据通常的规则进行验证,如果验证失败则抛出IllegalArgumentException.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!