2018/12/12 12:29

引用来自“我还在等你回家”的评论

作者我想转发一下你这篇文章,留你的原文地址,可以嘛
可以,到时候也留下新文章的地址吧
2018/12/12 11:04
作者我想转发一下你这篇文章,留你的原文地址,可以嘛
2018/12/06 19:24
运气好,从来没遇到过!按规范书写代码,很重要
2019/11/03 16:13
这些是我总结出来的经验,问题代码也不都是我写的,部分是接手别人的代码发现的。 发出来一方面是为了让大家尽可能避免写出这些问题代码,出了问题也能尽快找到原因; 另一方面是为了推广我的开源项目。
2018/12/06 10:51
第一个RequestRole.ALL,外部不能访问?
2019/11/03 16:12
不是不能访问,是从注解里取出来的值是空数组。 在非注解代码里拿到的值是正常的。
_-
2018/12/05 08:48
1.泛型擦除 还需要自己研究下
2. 基本数据类型的引用类型 自动装箱拆箱也需要好好学习一下.
2019/11/03 16:13
请问您怎么看出来我就不知道这些原理? 这些是我总结出来的经验,问题代码也不都是我写的,部分是接手别人的代码发现的。 发出来一方面是为了让大家尽可能避免写出这些问题代码,出了问题也能尽快找到原因; 另一方面是为了推广我的开源项目。
2018/12/04 21:55

引用来自“xiaoaiwhc1”的评论

三元表达式那个应该也不算是bug吧?编译期不能确定具体的值,等运行时才动态指定,那时候报错也没有什么问题。如果能在编译期就检查各个表达式的返回类型就好了。

引用来自“孤独的探索号”的评论

算,如果是
int num = response == null ? 0 : response.getInteger("num");
这个编译不报错能理解,毕竟getInteger返回值只能在运行时确定,
但如果硬编码就是null
int num = response == null ? null : response.getInteger("num");
就应该编译报错,避免开发者一时手误/眼误写错,或者需求改了后改代码不小心把 Integer num 改成 int num 等导致bug。

引用来自“xiaoaiwhc1”的评论

试了一下, 确实应该算bug.
int i = x > y ? null : 123; 编译器通过, 运行报错.
int i = x > y ? null : "123"; 编译器直接报错.
int i = x > y ? null : null; 编译器直接报错.
至少, 这里编译器出现行为不一致的情况了. 当然, 不了解源码, 不知道为啥.
int i = x > y ? null : 123这条,如果开发者的预期是if(x<=y){i=123}else{throw new Exception()}呢?这条并不是运行时总报错的,只是运行时有可能报错。下面那两条是无论什么情况都会报错的。
2018/12/04 20:27

引用来自“xiaoaiwhc1”的评论

三元表达式那个应该也不算是bug吧?编译期不能确定具体的值,等运行时才动态指定,那时候报错也没有什么问题。如果能在编译期就检查各个表达式的返回类型就好了。

引用来自“孤独的探索号”的评论

算,如果是
int num = response == null ? 0 : response.getInteger("num");
这个编译不报错能理解,毕竟getInteger返回值只能在运行时确定,
但如果硬编码就是null
int num = response == null ? null : response.getInteger("num");
就应该编译报错,避免开发者一时手误/眼误写错,或者需求改了后改代码不小心把 Integer num 改成 int num 等导致bug。
试了一下, 确实应该算bug.
int i = x > y ? null : 123; 编译器通过, 运行报错.
int i = x > y ? null : "123"; 编译器直接报错.
int i = x > y ? null : null; 编译器直接报错.
至少, 这里编译器出现行为不一致的情况了. 当然, 不了解源码, 不知道为啥.
2018/12/04 20:15

引用来自“guor”的评论

只能算错误的调用,并不是bug

引用来自“孤独的探索号”的评论

问题是并没有看到源码或文档里说明不能这样做,如果有麻烦告诉我哦。
另外能编译时解决的问题最好不要留到运行时,否则和动态语言比就少了一个很大的优势了。

引用来自“guor”的评论

我觉得并不是这样的,就好比 long a = Long.valueOf("a"); 按照你的逻辑,这种也是bug?既然给了异常,就说明你的调用是错的,如果编译能解决所有问题,那还要测试做什么?
所谓bug,是实际输出与理论不一致
你这上面列的,都是理论就是错误,实际还是报错,哪是bug

引用来自“孤独的探索号”的评论

这个当然不算,因为它不属于基本语法上的错误,Long.valueOf(String s) 这个如果要在编译时检查代价非常高,且收益并不大。

int i = 判断条件 ? null : 其它值
这是基本语法 三元表达式 里面就出现了不应该允许的值,应该和
int i = null
一样编译报错
int i = (判断条件 ? null : 其它值).intValue()。基础数据类型不能设置为null,所以编译器只需要验证null是不是可以转换为Integer,很显然是可以的。
Javap代码如下:

Code:
0: aconst_null
1: checkcast #2 // class java/lang/Integer
4: invokevirtual #3 // Method java/lang/Integer.intValue:()I
7: istore_1
8: return
2019/11/03 16:08
照你这么说,int i = null; 也不应该被编译器识别报错了
2018/12/04 19:18
经验问题,多看看书
2019/11/03 16:13
这些是我总结出来的经验,问题代码也不都是我写的,部分是接手别人的代码发现的。 发出来一方面是为了让大家尽可能避免写出这些问题代码,出了问题也能尽快找到原因; 另一方面是为了推广我的开源项目。
2018/12/04 18:10

引用来自“guor”的评论

只能算错误的调用,并不是bug

引用来自“孤独的探索号”的评论

问题是并没有看到源码或文档里说明不能这样做,如果有麻烦告诉我哦。
另外能编译时解决的问题最好不要留到运行时,否则和动态语言比就少了一个很大的优势了。

引用来自“guor”的评论

我觉得并不是这样的,就好比 long a = Long.valueOf("a"); 按照你的逻辑,这种也是bug?既然给了异常,就说明你的调用是错的,如果编译能解决所有问题,那还要测试做什么?
所谓bug,是实际输出与理论不一致
你这上面列的,都是理论就是错误,实际还是报错,哪是bug
这个当然不算,因为它不属于基本语法上的错误,Long.valueOf(String s) 这个如果要在编译时检查代价非常高,且收益并不大。

int i = 判断条件 ? null : 其它值
这是基本语法 三元表达式 里面就出现了不应该允许的值,应该和
int i = null
一样编译报错
2018/12/04 17:42

引用来自“guor”的评论

只能算错误的调用,并不是bug

引用来自“孤独的探索号”的评论

问题是并没有看到源码或文档里说明不能这样做,如果有麻烦告诉我哦。
另外能编译时解决的问题最好不要留到运行时,否则和动态语言比就少了一个很大的优势了。
我觉得并不是这样的,就好比 long a = Long.valueOf("a"); 按照你的逻辑,这种也是bug?既然给了异常,就说明你的调用是错的,如果编译能解决所有问题,那还要测试做什么?
所谓bug,是实际输出与理论不一致
你这上面列的,都是理论就是错误,实际还是报错,哪是bug
2018/12/04 17:33

引用来自“guor”的评论

只能算错误的调用,并不是bug
问题是并没有看到源码或文档里说明不能这样做,如果有麻烦告诉我哦。
另外能编译时解决的问题最好不要留到运行时,否则和动态语言比就少了一个很大的优势了。
2018/12/04 17:29

引用来自“xiaoaiwhc1”的评论

三元表达式那个应该也不算是bug吧?编译期不能确定具体的值,等运行时才动态指定,那时候报错也没有什么问题。如果能在编译期就检查各个表达式的返回类型就好了。
算,如果是
int num = response == null ? 0 : response.getInteger("num");
这个编译不报错能理解,毕竟getInteger返回值只能在运行时确定,
但如果硬编码就是null
int num = response == null ? null : response.getInteger("num");
就应该编译报错,避免开发者一时手误/眼误写错,或者需求改了后改代码不小心把 Integer num 改成 int num 等导致bug。
2018/12/04 17:29
只能算错误的调用,并不是bug
2018/12/04 16:09
三元表达式那个应该也不算是bug吧?编译期不能确定具体的值,等运行时才动态指定,那时候报错也没有什么问题。如果能在编译期就检查各个表达式的返回类型就好了。
回复 @
{{emojiItem.symbol}}
返回顶部
顶部
返回顶部
顶部