到底怎样写 try-catch，才能称之为高手？

try-catch，一个大家最常见不过的语法，但是有些人却用不好。当面对一个崩溃的时候，不管三七二十一先catch住再说，没错，老崩溃是被catch住了，但是新崩溃又出现了，想想都是坑啊，本文就和大家探讨下这个话题，此外买一送一，再和大家探讨下空指针异常。

乱用try-catch

写过C++的人都知道，那异常捕获特别不好用，甚至有些异常还捕获不了，在Java中，try-catch特别好使，如果一个人的代码没有try-catch，有时候会被大家质疑代码写的不健壮。

try-catch虽好，但不可乱用，原因在于try-catch可以隐藏代码缺陷，不利于bug排查。如果没有try-catch，那程序会崩溃，崩溃后从日志中可以一眼看出问题的原因。而如果用了try-catch以后，崩溃被catch住了，这个时候程序没有崩溃，但是程序运行会不正常。

我相信大家都明白：crash并不可怕，可怕的是crash后却没有找到日志，你就慢慢去查吧，这感觉谁查谁知道。

举个例子来说明下：

public class Example {public static void main(String[] args) {BusinessLogic bl = new BusinessLogic();bl.doA();bl.doB();bl.doC();bl.doD();bl.doE();}}class BusinessLogic {public void doA(){System.out.println("I am doing A");}public void doB(){System.out.println("I am doing B");}public void doC(){int i = 1/0;System.out.println("I am doing C");}public void doD(){System.out.println("I am doing D");}public void doE(){System.out.println("I am doing E");}
}

上面的程序有个问题，在doC函数中存在除0异常，程序运行后会崩溃，我们可以得到如下日志反馈：

I am doing A
I am doing B
Exception in thread "main" java.lang.ArithmeticException: / by zeroat BusinessLogic.doC(Example.java:27)at Example.main(Example.java:7)
sandbox> exited with status 0

但是有的程序员，特别害怕崩溃，为了让自己的程序不会崩溃，直接在最外层进行try-catch：

public class Example {public static void main(String[] args) {try {BusinessLogic bl = new BusinessLogic();bl.doA();bl.doB();bl.doC();bl.doD();bl.doE();} catch(Exception e) {e.printStackTrace();}}}

结果，程序是不会崩溃了，但是逻辑并没有正确地执行，这个时候如果让你去排查这个问题，你能第一时间定位到doC函数有问题吗？我觉得大部分人都不能。

虽然这个例子看起来有点可笑，但是在实际开发中确实看到过不少这种现象，更有甚者，连e.printStackTrace()这句话都懒得加，程序没有任何异常日志，想排查这种错误简直痛不欲生。

空指针强迫症

前面说到崩溃，大家知道排名前2的崩溃是什么吗？没错，那就是：

大家可以检查下自己的项目，看看这两个异常是不是占大头。所以，为了防止空指针异常，很多程序员会这样写代码：

public class Example {public static void main(String[] args) {BusinessLogic bl = new BusinessLogic();Object param = new Object();bl.doA(param);}}class BusinessLogic {public void doA(Object o){if (o != null) {System.out.println("I am doing A with param : " + o);doB(o);}}public void doB(Object o){if (o != null) {System.out.println("I am doing B with param : " + o);doC(o);}}public void doC(Object o){System.out.println("I am doing C with param : " + o);}}

上面程序犯了一个错误，那就是重复判空，大量的冗余判断会影响程序的性能，上面的例子很简单，我相信大家都不会犯这个错误，但是当项目大了以后，当函数调用错综复杂的时候，你还能保证自己不犯错吗？很难！

大家还记得C语言的strcpy函数吗？

strcpy(char * __restrict to, const char * __restrict from)
{char *save = to;for (; (*to = *from); ++from, ++to);return(save);

可以看到，C语言的strcpy函数，没有进行任何判断，比如你传递个空，或者说to的长度比from小，这些都会导致程序异常，但strcpy依然是不做任何判断，为的就是追求高性能。

对于strcpy来说，异常判断是上层调用方该考虑的事情，它作为底层API并不需要关注那么多，如果上层调用不合法，那就让程序挂掉就行了，谁叫你不按我的要求来呢！

这个涉及到架构设计的理念，我们在开发一个sdk的时候，其实是不需要每次都校验参数合法性的，明确对外暴露的API，如果说外部调用不合法，一定要让程序挂掉，而不是不回应，这样上层也更好排查问题，尤其是一些调用频次较高的底层sdk，更要注重这一点，性能和调用反馈是我们需要注意的。

这就好比搭积木，我们无需保证每块积木都是完全可靠的，但是每个积木之间无缝衔接，没有多一点，也没有少一点，而是刚刚好，它们共同构成了一个完整健壮的个体。写程序也是如此：

无需做诸多冗余的保证，只要各层级的代码能够无缝衔接就好

这就是我心中的代码设计理念，大道至简，简单到每个人都能理解。

以上就是我要分享的，原创不易，给点个在看呗，大家周四快乐！

推荐阅读你们吹捧的鸿蒙，只是另一个Fuchsia探索Flutter异步消息的实现互联网 HR 黑话大全，太真实了！