java中的异常说起来简单，但是用起来却完全不是你想象中的那么简单的，现在我来说一下自己理解的具体情况的具体用法
Java中的异常大致分为两类，可查的异常（checked exceptions）和不可查的异常（unchecked exceptions），说白了可查异常就是必须try catch 的，不然编译报错，例如IOException、InterruptedException，不可查异常就是可以不用try catch，例如我们最熟悉的NullPointerException，只要继承了RuntimeException都属于不可查异常，现在说一下我的经验。
错误示范1：遇到可查异常就try catch
比如以上代码，大家觉得会有什么问题吗？想过吗？如果插入队列的时候真的出现了异常，那上层代码也会认为我执行成功了，因为没有报错呀，瞎执行一通后造成各种各样的逻辑错误，可以看下图的执行，produce就算出现异常也会成功保存数据？到时候你找问题就扑街了，为什么数据库有数据，队列里就没有呢？没事，慢慢找吧
错误示范2：万恶的printStackTrace
回到更能够给的问题，怎么找原因？诶， 我不是在catch里printStackTrace了吗？看我多机智。好， 这个日志有100G，慢慢翻，如果再分布在100台的服务器集群里，保证你怀疑人生，现代化企业级的项目里千万不要出现System.out.println输出这种低级错误，printStackTrace就是用了他，这些日志打出来连最根本的出错时间都没有，更别谈对日志进行搜索了
说完了错误示范，那这些错误怎么避免呢？什么时候该使用可查异常，什么时候该使用不可查异常呢？
错误示范1里，我们盲目的捕抓异常，错误示范2里，异常没有正确处理，后果很严重，但是异常处理和实际业务关联性是非常强的，我也不能说出一套通用的解决方案，我说一下特定情况下的特定解决方案。
我们必须告诉上层调用这次执行失败了，方法如下图
这样上层调用在出现此异常时就不会向下执行错误的逻辑，但其实还是有一个问题，因为这是一个可查异常，上层调用代码必须要对这个异常做出处理，继续往上抛还是捕抓，其实我个人是不喜欢使用可查异常的，这也是其中一个很重要的原因，上层调用必须因为你的异常加入一些不必要的代码，所以我的修改是
这样上层调用就不需要因为调用了这里的代码而必须做出一些改变了，当然是用RuntimeException还是有一点争议的，你可以替换成你自己的自定义异常，但是一定要是集成RuntimeException的
当有一些异常我们必须要处理的时候怎么办呢？
我们有一个这样的操作，当请求失败后，捕抓异常，把数据保存到数据库里，也不是所有的异常都需要往外抛，但是我还是建议可以加上日志，有利于日后排查问题。
结论
异常本质上就是这一行代码告诉我他执行出错了，你自己看着办吧。这异常我没法处理，交给上面的老大哥吧，或者你觉得这个异常是在我的接受范围内的，我可以处理。我觉得最经典的使用案例就在我们的事务管理上，事务老大哥会根据下面的小弟反馈有没有异常判断是提交还是回滚，如果有些不听话的小弟把本应该要回滚的异常吃掉了，事务老大哥不知道，后果就很严重了。你做不了决定，就交给你上面的老大哥吧。
