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

柔光的暖阳◎ 2022-10-16 09:52 168阅读 0赞

#### 背景 ####

*  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\"}"}

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

#### 小结 ####

*  **注意事项**

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