try catch 和 if 在处理程序可能的出错上有什么区别?

[aoscici2000]

比如说抽取文章前 100 字作为简介, 两种方法有什么区别

String content = ".........."

try {
    content = content.substring(0, 100)
} catch (StringIndexOutOfBoundsException e) {
    // pass
}

if ( content.length() > 100 ) {
    content = content.substring(0, 100)
}

[a719114136]

区别就是一个 try catch 和一堆 if。
当然 java 的特性，很多时候你必须 try catch

[xiaopang132]

如果程序出现了 catch 中的异常,程序会继续往下跑,但是如果 if 中出现了异常,程序会停止.

[linxb]

try catch 可以处理一些程序中断的异常

[questionlin]

try...catch 的设计是，一个程序只有一个，一般在最外层，统一处理所有错误

[chendy]

区别是第二种更已读，性能也更好
除非必要否则不要用捕获异常的方式做业务

[msg7086]

异常一般用在程序员假定本应正常工作的情况； if 一般用在程序员假定本来就可能会触发的情况。
比如，如果 content 是用户输入，那么用户输入多少字都有可能，所以用 if。
如果 content 是某个专门输出大量文章的函数输出的产物，正常情况下都应该输出超过 100 字内容的，如果少于 100 字那就是程序工作不正常了，这种时候就可以用异常。

异常说白了也是 if 触发的。substring 里有 if (length <= 100) throw StringIndexOutOfBoundsException。

[q8164305]

异常一般只用在程序员不能控制的地方，如能控制，尽量不用异常

[geelaw]

@a719114136 #1
@questionlin #4
这个想法非常危险，如果不细致地处理异常，外面的处理器通常不能明白到底发生了什么，如果这时继续运行将会带来不可预料的结果。

@msg7086 #6
不全是，比如所有的网络访问都应该被假定可以失败，但是很多高级语言中只能通过 try...catch 来捕获异常（因为错误代码已经被转换为异常）。

——————

回到题主提到的问题，第二种写法效率更好。

[palmers]

1. 在 java 中， 异常栈是有成本的， 在这段代码里， 很明显的 if 判断的成本远远大于异常栈的成本；
2. 在程序设计上， 能够提前预知的异常都不应该依赖 catch 去帮你捕获；很多 java 程序设计的书籍也有提到不应该利用异常栈做流程处理， 在这里也是类似的道理;
3. 使用 try...catch 一般都是为了容错，而不是为了用来做类似判断的逻辑处理;

[palmers]

@palmers 对不起 第一条写反了 反正大概意思你明白就行

[zqx]

正常的语言里，try 都是用于捕获未知的错误，如果你都知道这个表达式在某些条件下一定会抛出错误，那就应该用判断条件说明它

[kzfile]

错误天然可以传递
使用 if 你一般要在发生错误的上一层处理错误.
但使用错误传递,你可以有更多的选择

[lithiumii]

java 不懂，反正 py 是偏好 EAFP （ Easier to ask for forgiveness than permission，字面意思：请求原谅比请求许可更容易）多于 LBYL （ Look before you leap，字面意思：跳之前先看清楚），然后 EAFP 的用法一般就是 try 后面再 catch 已知的特定错误（反正你没事儿别一口气 catch 所有的错误就是了）。

[NoKey]

if 能判断的，你用 try 去搞，你这个写法，我还是第一次见啊。。。

[niubee1]

一般的语言，只能 return 一个值， 而错误包含了 3 个信息，1 是是不是错了 2 是是啥错 3 是出错的地方提供了啥信息。 你说一个强类型的语言要怎么优雅的弥合这个鸿沟？而异常机制是另开通道来把正常逻辑和错误处理逻辑解耦开的方式， 保证了正常的业务逻辑不受到错误的影响。 而基于返回值的方式处理错误，是等于把处理错误作为了业务逻辑必须关心的话题了， 这样简单直接， 但是面对复杂的容易出错的部分耦合在一起的逻辑就会显得很杂乱，因为内部正常逻辑和错误处理逻辑是交织在一起的。

[rizon]

真较真这个也没啥意思，从结果上看似乎一样，但是每个语句都有自己的使命，就算其他语句能达到这个效果，但毕竟不是为此而生的。
你要真说 try 代替 if 这种非主流做法有什么坏处，也是有很多的。
catch 的 oob 异常你怎么知道是 endIndex 超出了，还是 beginIndex 超出了？
在一些其他的方法里，如果你不判断而是直接运行，看看结果如何，那么有些事情在方法里被执行了，然后才抛出问题，小了说这就是浪费，而对于有副作用的函数那就是直接不对了。

[FrankHB]

Locality 和 exception/error neutrality 都没人提就算了，影响 signature 都不管了（好吧好像有一位提了）？ Java、Java ……
要跨过程传播错误状态，你一个个改返回类型？还是先发明个 longjmp ？（习惯没事人肉糟蹋 throws 的当我没说。）
当然 LZ 这种立即原地 catch 的玩意儿就是 try 反面教材。

[pkookp8]

@niubee1 我觉得所有这三个信息都可以归结于返回 0 或非 0 来表示。
只要有提前约定

[blless]

就感觉很多人连错误处理都不会 一般业务最上层有 try catch，程序内部基本不用了，尽管抛出异常就是了，最上层处理异常就好。业务超出本机控制代码，一般都要额外 try catch，比如网络，磁盘之类的 IO 请求，需要根据业务处理直接抛出还是重试。按我理解一个应用三层 try catch 就够用了

[annoymous]

EAFP 与 LBYL 是两种编程风格 爱用哪个用哪个