try catch 合理使用

什么时候使用try catch语句模块，是不是没有明确的答案？

来自网友的回答：try catch是程序语言本身提供的一种异常处理机制，你大多数写的代码都是要调用底层的api，而这些api的作者在开发api时，很清楚api在使用的过程中会有哪些非正常情况发生，因此他要通知api的调用者，至于对于这种非正常情况怎么处理，就交给了api的调用者。

你是写代码的，你要调用api，因此你就说api的调用者，你也应该处理api本身存在的非正常情况，那你怎么处理这些非正常状况，这就是你提到的try catch的作用了，它就是干这事的。至于api会有哪些非正常情况发生，需要查api的帮助文档；这些非正常状况怎么处理，这又取决于问题逻辑了，跟实际需求有关系。
try{A程序块} catch{Exception e}{B程序块} 。。。。。

A程序块比较有可能会出错的地方，B则是如果A中有了错误，进行的处理。就好比，一个流水线上，如果有个地方有个产品堵住了不通了，如果没人处理，则整个流水线就没法动作了，要想保证整个流水线的运作则要有人把这个产品给处理了。try语句就是对A程序块的语句进行捕捉有可能出错的地方，相当于流水线上那个检查的人，catch语句则是处理的.

什么情况下需要用try-catch呢，那就是不使用这种try结构时，代码报错退出就无法继续执行。有的代码出错就应该退出，有的出错尚可以补救，就不应该退出。对于这种出错不应该退出的就需要使用这种结构，在catch中进行补救。例如，写入一个日志文件，如果这个日志文件被锁定或者占用，那么写入就会出错退出，但是我们并不想看到这样的情况，我们完全可以换一个名字再写入。

有的函数或者功能调用之后不会出错退出，但是会返回错误码，这个时候也不需要使用try-catch结构。直接根据不同的错误码进行分类处理就行了。
所以不是trycatch使用量的问题，还是看应用场景，如果确实需要防止异常退出，需要多次补救，那么再多都是不为过的。
还有一个情况要注意，try-catch不是能够解决所有的出错退出，例如php中的segment fault，也就是熟知的段错误，就算是try-catch了也还是会退出，这个时候需要使用gdb进行调试解决了。

try catch后是不是一定要输出异常信息？或者有没有更好的办法去处理日志信息呢？                                                                                  
如果每一段程序都try catch后输出日志，会导致日志信息臃肿不堪，无法从日志中读取有用的信息，使得解决问题更加困难。那有没有统一处理日志信息的工具包呢！规划好日志信息，异常信息将更加清晰明了，同时多读日志可以不段优化程序减少异常的发生情况，一举多得何乐而不为!

LOG4J学习
定义：Log4j是Apache的一个开放源代码项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件、甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等；我们也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，我们能够更加细致地控制日志的生成过程。最令人感兴趣的就是，这些可以通过一个配置文件来灵活地进行配置，而不需要修改应用的代码。
程序开发环境中的日志记录是由嵌入在程序中以输出一些对开发人员有用信息的语句所组成。例如，跟踪语句（trace），结构转储和常见的 System.out.println或printf调试语句。log4j提供分级方法在程序中嵌入日志记录语句。日志信息具有多种输出格式和多个输出级别。
使用一个专门的日志记录包，可以减轻对成千上万的System.out.println语句的维护成本，因为日志记录可以通过配置脚本在运行时得以控制。 log4j维护嵌入在程序代码中的日志记录语句。通过规范日志记录的处理过程，一些人认为应该鼓励更多的使用日志记录并且获得更高程度的效率。

使用log4j大概涉及3个主要概念:
公共类 Logger Logger 负责处理日志记录的大部分操作。
公共接口 Appender Appender 负责控制日志记录操作的输出。
公共抽象类Layout Layout 负责格式化Appender的输出。