java底层处理try catch_不明白为什么java要用try....catch...。不用完全没有影响啊？...

try catch就是用于错误情况的处理啊。

我先按照自己的理解介绍程序错误处理的几种方式。再介绍异常机制的利弊。最后谈谈我对异常机制的看法。

首先看程序的行为：输入-》程序-》输出。

比如有一个方法，处理一件事，然后返回处理结果。一般做法是把return结果作为输出，然后方法参数作为输入。

但是程序难免会出现错误，健壮的程序都需要考虑极端情况或者错误情况(有些错误是由于外部环境造成的，比如网络内存等)，不能放任这些异常情况不管。所以开放了一个通道来作为错误情况的返回，这就是异常。

就像Linux的stdin，stdout，stderr一样，标准输入，标准输出，和错误输出。异常就是对应了stderr这种方式。

当然同一件事可以有很多种方式来做，比如方法参数也可以作为输入输出，甚至异常也可以用方法参数来获取。比如很多操作系统的调用都是这样的，用一个引用作为参数传给函数，然后执行，最后访问这个引用获取执行结果，甚至判断是否有错误出现。

那么为什么要用异常机制(try catch)来处理这些错误情况呢？

你想想看，假如没有try catch，你每调用一次函数，都需要去判断执行结果，判断方式自然是if else。

当程序中这些会出错误的函数少还好，但是假设你一段代码中有大量的程序要做这做判断，而且一般都是相关的代码放在一起的。这就意味着后面执行的逻辑会依赖你前面语句的执行情况，也就意味着你每调用一个可能会出现错误的函数的时候，都要判断是否成功，然后再继续执行后面的语句。导致你的这段代码中充斥着大量的if else。

更极端一点，假设你的这段充满了if else判断的代码封装在某个函数里面，然后外层又有函数调用你这段函数，是否意味着外面这个函数也要去判断异常情况？你的错误可能会使用某个整数来作为错误代码，来表示不同的错误情况，可能会大大影响程序的可读性。而且每一层代码的错误处理都要和你的逻辑代码混在一起，写到最后你自己都会觉得恶心。

异常机制(try catch)就是用来解决这个问题的。

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

但是，异常机制(try catch)也是一把双刃剑，过多的异常会导致代码臃肿，有时候写几行逻辑代码，往往会出现好几倍的异常处理代码，抛出一大堆各种异常，最著名的就是jdbc了，写个数据库查询，出来一大堆异常，最后finally里面connection close也要处理异常，影响写代码的效率。

还有就是程序员嫌异常太多懒得处理，catch住了异常就啥也不做，或者整个异常处理的代码写的太不雅观。

针对第一种有大量的重复的异常处理的情况，其实有很多框架都提供了解决思路，比如使用template，把大量重复逻辑的异常代码使用模版解决掉。

现在也流行使用非受检异常，比如runtimeexception这种，不强制你写try catch代码，在某些不太容易出异常情况的地方很有用，简单粗暴但是很有效果，能大大降低代码量。比如有些框架封装了jdbc，同样把jdbc里面的受检异常改成非受检异常重新throw出来，这样外部程序就可以不用写try catch了。

综上，异常处理机制是一种很好的处理程序异常情况的方法，但是貌似现在人们很容易忽略异常处理，或者厌恶这种写法。的确，有时候它真的很令人讨厌，但大家不妨换个角度看待它，异常用好了可以改善代码，增加可读性，用巧了可以减少代码量，把代码变得优美。也可以增加很多自定义的异常，来表示程序特定的错误。

但是，异常虽好，可不要贪杯喔。合理的使用，在设计中找到一个平衡点，才是一个工程师基本的节操！

java是一门工程性的语言。

其实工程就是一门艺术：艺术家寻找美，什么是美？和谐就是美，调整布局和颜色，在各种元素中间找到一个平衡点，达到一种和谐的点，这才是艺术家的实力。工程也是如此，工程师需要在各种条件下进行取舍，牺牲某些特性来达到某些方面整体的提高，最终完成了项目。

软件设计师在代码里面实现艺术，架构师在项目层面实现自己的艺术，其实大家都是艺术家，只是谁画的好谁画的差。

而java，私以为，是一件艺术品。她不是中庸，她是和谐。