java – assert(false)vs RuntimeException?

前端之家收集整理的这篇文章主要介绍了java – assert(false)vs RuntimeException?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在阅读 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,或者可能是一个错误

@R_301_323@

最大的区别
assert false;

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

throw new RuntimeException();

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

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

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

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

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

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

原文链接:https://www.f2er.com/java/130124.html

猜你在找的Java相关文章