细节决定成败（一）：处理json格式的字符串要多注意细节

背景

• json格式的字符串，注意类型，是java类型的String还是实体类型（对象）
• 根据接口文档写代码的时候，对有疑问的地方要提出来。

过程

• 接口文档响应报文

{"rspCode":"0000","rspDesc":"操作成功","uuid":"ec6865ca-7a1d-41ad-a9f2-23b792417f1","body":{\"id\":\"17610522126516\",\"preNumber\":\"1760032825\",\"shortUrl\":\"https://uc.g.cn/AkxXrTi9\"}}

• 分析

1. 我们一般第一时间会默认这个body的类型，应该是一个实体类型。
2. 于是，我们实际代码也会很自然用实体类型进行转换。比如使用fastJSON的parseObject()方法即可。

• 实际情况

1. 我的代码并没有打印接收到第三方的响应报文的最原始数据信息，而是先调用了fastJSON的parseObject()方法。
2. 而第三方的响应body类型其实是字符串，而不是实体。如下：

{"rspCode":"0000","rspDesc":"操作成功","uuid":"ec6865ca-7a1d-41ad-a9f2-23b792417f1","body":"{\"id\":\"17610522126516\",\"preNumber\":\"1760032825\",\"shortUrl\":\"https://uc.g.cn/AkxXrTi9\"}"}

3. 结果：我在调用fastJSON的parseObject()方法，导致抛出异常，而我的代码先进行了try catch, 然后进行了e.printStackTrace()打印，然后抛出一个未知异常，这个未知异常我也不知道什么原因，也可能是其他业务逻辑问题，业务逻辑过程处理稍微有些复杂。
4. 第一，e.printStackTrace()一定会打印堆栈信息的，但是一定要注意顺序问题，堆栈信息与这个抛出的未知异常日志一定不是顺序输出的。第二，因为请求量大导致日志多，如果定位日志的话，还是有点儿困难，因为堆栈信息的关键字不知道。
5. 解决找到日志错误的办法：用log.error()这个方法，打印e.toString()内容，看看究竟是什么样的报错内容，然后，反推可能出现这样错误的代码。com.alibaba.fastjson.JSONException: syntax error, expect {, actual string, pos 87, fieldName body 。还是要仔细阅读错误信息，不要着急，想着解决问题。这个信息告诉我们：我们是需要java实体，然后却给我一个字符串，还给出了哪个属性字段，稍微细心一些，就特别好解决。
6. 如果想要把body中的内容转为实体。需要两个步骤。第一，字符串类型的body接收到。第二，在把这个字符串转为一个实体。通过fastJSON.parseObject()方法即可。

小结

• 注意事项

1. 横向开发过程中，跟系统之间的任何交互过程中，一定要把请求参数和响应参数打印出来，而且一定是打印响应报文的原文，千万不要自己代码进行了响应报文的处理，然后在打印。这个特别重要。
2. 如果不确定是什么类型。需要主动去询问清楚，究竟是什么类型。所有环节自己认为有问题的地方，都要提出来。
3. 要想排错还是要第一时间想办法如何新增加一条日志记录，这个一条日志记录一定要把错误的详细信息记录下来。靠读代码，分析，解决的效率非常低效。一定是第一时间弄一个日志。