今天主要和第三方支付公司进行支付接口的对接，前期已经对接过，但是姿势不正确，修改成成姿势正确的步骤。
遇到的问题：
由于是restTemplate发送post请求，故使用main方法调用。调用报错401 Unauthorized 未授权。
想到的解决方案：遇到这个错误肯定是调用接口的签名signature或者token不正确，故询问为何不正确，帮助我查看code哪里不正确，但是给出的答案是正确的，仅仅是看了代码没进行运行测试。让我自己找原因。
我就自己翻来覆去的测试各种情况，但是最后还是失败告终。实在是没有办法，请教对方的研发负责人查看，但是他还是看不出来什么问题，就让他看我请求的日志，让他看看是不是请求过了，最终发现了原因，是我请求的body数据不正确，这个错误的原因是因为我看到错误401Unauthorized绝对想到的不是body有问题，401错误是未授权，是signature和token的问题，绝对不会是body造成的，但是对接人的一句话把我气个半死，他们针对错误统一封装，一般都是401Unauthorized和403 Forbidden是signature和token错误。我内心一万只羊飘过，不能把异常吞并的这么厉害把，已经完全曲解了错误的本质，最后把body修改，重新发起请求，正确结果。
思考：
针对异常的封装，尤其是提供接口的异常封装，一般都是封装一个消费者可以理解的错误，这个错误是非常有必要的，因为他可以1，提高系统的友好性，比如文件查找不到，提示用户一串的英文异常，使用者估计会打死你2，提高系统的可维护性，错误消息针对性提示，消费者使用的时候会马上发现自己的问题所在或者接口提供者的错误所在，及时的发现并且解决问题3.解决Java异常机制自身的缺陷， java会吞并异常，并且只会抛出一个异常，我要是抛出了多个异常，这个时候就需要自己封装了。
说了这么多的好处，咱们来说说坏处，如果是没有经验的或者系统在架构的时候如果没有处理好异常机制，会导致一大堆的坑，这个坑对使用者是无比的糊涂，并且难以发现问题的所在。比如异常处理吞并，异常曲解等，所以说一个好的封装异常机制是很重要，如果偷懒统一抛出一个没有人能看懂的错误，自己受累，调用者也受累，何苦呢？何必呢？
个人建议：
1，如果是针对客户端的错误，可以友好提示用户错误，但是log一定要记录清楚。
2，针对接口对接使用的，可以不必封装的那么完美，因为大家都是开发者，把错误封装到一个对象里面，message就是错误消息，在调试的时候很好的发现问题。
写于2018/08/10 晚11:20