@xiangyuecn #49 二进制只是构成世界的基本结构,但是从人类的角度看一个事务的结果不可能只有 true 和 false 的
所以单纯的用 0 和 1 去理解世界就是自讨苦吃,刚入门的我也苦恼过好久

@wly19960911 #45 可以放弃 rxjava 了,java8 有 completablefuture,java9 有 flow 已经完全可以代替 rxjava

@hehheh #44 所以我认为坚持不使用 try-catch 的人要么是新手没写过复杂的多层的逻辑或者根本没有分工合作的经验,肯定没写过自定义异常和尝试设计框架

@wly19960911 #34 看了你的我才发现 24 楼貌似是不推荐 try-catch 的,而是用所谓的 result 封装
带来的后果就是膨胀和无穷无尽的 if else

@ragnaroks #38 滥用是人的问题,不是 try-catch 的问题,而且不用 try-catch 更加可怕

@wly19960911 #37 我已经不怎么想回答"try-catch 会有性能问题"这个问题了,java 从来就不以高效著称要追求极致效率请出门右转 C 语言,代码逻辑一塌糊涂还谈什么运行效率?

@lcdtyph #31 32 楼说得非常明确了,希望你多阅读和理解
@anonymous256 #32 感谢回答和解惑,世界有你更精彩!
@wly19960911 #34 很多人开发的时候脑子里其实是个单线程,只会思考当前方法怎么写而不会思考上下级调用,兼容性,扩展性,导致代码一团糟,人菜不能怪语言

@lcdtyph #29
你想想看，假如没有 try catch，你每调用一次函数，都需要去判断执行结果，判断方式自然是 if else。
当程序中这些会出错误的函数少还好，但是假设你一段代码中有大量的程序要做这做判断，而且一般都是相关的代码放在一起的。这就意味着后面执行的逻辑会依赖你前面语句的执行情况，也就意味着你每调用一个可能会出现错误的函数的时候，都要判断是否成功，然后再继续执行后面的语句。导致你的这段代码中充斥着大量的 if else。
更极端一点，假设你的这段充满了 if else 判断的代码封装在某个函数里面，然后外层又有函数调用你这段函数，是否意味着外面这个函数也要去判断异常情况？你的错误可能会使用某个整数来作为错误代码，来表示不同的错误情况，可能会大大影响程序的可读性。而且每一层代码的错误处理都要和你的逻辑代码混在一起，写到最后你自己都会觉得恶心。

异常机制（ try catch ）就是用来解决这个问题的。
异常机制将所有的程序异常的情况和正常执行的代码分离开来，并提供统一的代码去处理不同的异常，而且针对不同类型的异常情况定义了不同的异常类，用于表示不同的异常情况，增加代码可读性。java 还提供了受检异常和非受检异常，受检异常会强制你去写 try catch 去处理异常情况，否则可能导致编译不通过，这对代码的健壮性很有帮助，避免人为的遗漏异常处理。

@guyeu #32
你想想看，假如没有 try catch，你每调用一次函数，都需要去判断执行结果，判断方式自然是 if else。
当程序中这些会出错误的函数少还好，但是假设你一段代码中有大量的程序要做这做判断，而且一般都是相关的代码放在一起的。这就意味着后面执行的逻辑会依赖你前面语句的执行情况，也就意味着你每调用一个可能会出现错误的函数的时候，都要判断是否成功，然后再继续执行后面的语句。导致你的这段代码中充斥着大量的 if else。
更极端一点，假设你的这段充满了 if else 判断的代码封装在某个函数里面，然后外层又有函数调用你这段函数，是否意味着外面这个函数也要去判断异常情况？你的错误可能会使用某个整数来作为错误代码，来表示不同的错误情况，可能会大大影响程序的可读性。而且每一层代码的错误处理都要和你的逻辑代码混在一起，写到最后你自己都会觉得恶心。

异常机制（ try catch ）就是用来解决这个问题的。
异常机制将所有的程序异常的情况和正常执行的代码分离开来，并提供统一的代码去处理不同的异常，而且针对不同类型的异常情况定义了不同的异常类，用于表示不同的异常情况，增加代码可读性。java 还提供了受检异常和非受检异常，受检异常会强制你去写 try catch 去处理异常情况，否则可能导致编译不通过，这对代码的健壮性很有帮助，避免人为的遗漏异常处理。

@sunznx #30 就让他们活在"try-catch 性能差老师说过不要用"的世界吧,同样的还有"不要用 in 因为不会走索引"

@kidlj #22 java 在这里等着 go 来革命,加油!

@undeflife #24 Check Exception 在很多时候确实没屁用......

@wly19960911 #23 同样不喜欢 3,会导致方法的返回值结构完全被污染而且多层之间的定义可能完全不同,同一个标识为 1 的异常在不同层面的含义又不一样需要分开处理和转换

@scriptB0y #19 try-catch 是不建议滥用的例如用 try 包裹整个方法中的代码,但是这不是不用 try-catch 的接口不能因噎废食
这种 null 的检查 java8 中用 optional
工具是给人使用的不是放在头顶当神明敬畏的

@crclz #24 文章发一下谢谢,我放日经里去,下次不废口舌直接甩脸上

@crclz #24 赞同,业务异常和程序异常分开处理是对的
@felixlong #25
@guyeu #26 求求你们在 9102 年不要坚持这种愚蠢的想法了

@kidlj #15 能不能直接发表你的看法?

@HongJay #13 错误都可预知了还要用 try 干嘛?你没看这个回复的评论吗.
@ClericPy #14 只是方便看原文而已,我放上面你样会跳出来杠"原文都有了你还复制一堆出来干嘛",所以你只是为了杠而已

@guyeu #11 我有点觉得这些不用 try-catch 是假 javaer,不用 exception 处理异常流程简直没法写代码,用状态码会污染正常的方法结构不用状态码又没法告知上一层我出异常了,他们怎么写代码的?天天只写 void 的吗?