程序处理中往往会用到异常、log及其组合。程序的好坏在某种角度上来看也体现在了此类工具的使用上。对于异常，我们可以catch住，将错误信息记录log；也可以将exception抛出去，交给调用者去处理。但对于底层底层封装的接口或框架工具而言有些异常还是要抛出去的。
今天整理公司对FileNet API接口的封装，主要做的事情是将catch住的异常释放开抛出去。对于封装好的组件来讲，它本身是一个工具，是要能够让上层用户很好的使用，如果catch住例外，势必导致整个系统无法得之一些异常信息，更不用谈对相关例外做出合理处理了。例如，在开发中的ECM系统诸如流程、履历关键信息等需要FileNet与DB同步或相互补充配合，而某种异常出现时，也许操作DB使用的接口（例如OPENJPA）很容易遇到异常进行了回滚。异常出现点如果是DB方面还好，但如果是FileNet接口方面，使用了公司这套接口后，则捕获FileNet
异常，导致DB的数据依旧写入，DB和FileNet数据不一致。这也是成熟框架所不能疏漏的问题。
在一个代码块或一个功能点上可能需要处理的异常不止一处，可能异常相同也可能很不相同，这就要综合分析这些异常捕获的粒度，权衡此块功能遇到异常可能要告诉调用者多少种信息了。但有一点应该明确，就是无论这个功能块捕获多少次异常，每一次捕获异常时都要捕获尽可能小的异常，而不要定位父类异常让问题不清晰。
对向上抛出的异常可以是基础异常（例如java自身含有的异常），也可以是针对不同项目所使用的异常。对异常信息进行整理归类进行编码，使用编码来传输相关异常信息在实践中还是值得尝试的。而对于异常接收方在处理时一定要根据问题的性质适时做好相关操作，例如
本文讲述了底层支撑性框架或组件要将有效异常信息抛出去的重要性，并对不同代码逻辑所捕获异常的粒度进行综合分析，将最能说明此功能块产生问题的几种最小异常抛出从而精确定位问题的思路进行了概述。其关键点在于合理利用异常和log，而这只是优良软件的一小部分，然而单讲exception和log在代码中的作用和深远意义也不止于此。