用户上传JSON数据到我们服务端，我们需要进行解析处理，之后我们再上传到云端。现在我们这边有两种意见：
第一种就是在服务端进行JSON格式校验，包括解析后需要上传到云端的数据都需要进行校验后才上传。因为JSON嵌套的层次较深，我们每解析一层都需要判断是否为空。只要出现为空就直接进行错误处理。
第二种则是假定用户上传的数据都是合法的，只要在最外层捕获一个异常，保证该线程不会挂，里面解析和处理都不用做任何判断和校验。两种各有利弊，请问下这种情况，一般该如何处理？
1、上传之前判断关键数据是否为空
2、上传到服务端全部验证
3、展示或用的时候，要处理异常
看你们对出现为空的数据的定义是什么：如果正确的数据允许出现空，就要进行空判断和错误处理；如果出现空肯定是错误的数据，那么在外层捕捉异常即可。
不正确的数据必须挡在第一道大门之外。
首先不能假定处理失败（抛出异常） == 数据有错误。这两点肯定没有必然的联系。总会有数据业务逻辑上必须，但不填却不会引发程序的致命错误。
当然也可以说把数据的校验，跟随着事务处理的过程逐步进行。但这会导致两个问题：
- 时间的拖延，不能立刻得到数据合法与否的反馈结果；用户总是会用各种想不到的办法试验API，他们希望犯错时得到立刻的反馈，而不是等服务器处理半天失败了才知道。
- 执行了一半的事务还要特意丢弃，浪费服务器处理资源，绝对不如对非法数据干脆就不开启事务。
请坚持得到用户数据输入时第一时间进行校验。对于RESTful风格API而言，你可以考虑返回对应的HTTP错误状态码以及JSON格式的错误信息正文，帮助用户得到正确的反馈。
题外话。
对于API接口还差一点儿。但对网页表单接口来说，在这个目的上Node.js就会体现出绝大的优势：对于Node.js程序来说，前端和后端的数据校验代码是直接复用的！
如果对于一般的PHP后端来说，可能就要想点办法了。我建议可以自己规定一套统一的JSON格式校验表，定义哪些数据字段需要哪些约束条件（required、email、number等），然后前后段查同一张校验表，去写通用的代码做校验。
比较忌讳的是同一个目的的校验代码，手工用原生的JS和PHP写两份——维护两份同样目的代码的同步，做过就知道会死人了！
异常和线程挂掉有必然联系吗？数据异常校验导致线程挂掉，只能说是程序的异常处理机制没做好。很多人都喜欢捕捉到异常后直接抛出堆栈信息，而不是对异常进行处理，每次见到这种处理，我都会抓狂。抛出了，还得去分析抛出原因，甚至是分许需求，坑人呢。例如：if(){....},这样就结束了。我靠。else呢，就算你不记录日志，或者其他处理，至少也得打印一下，让人一调试就知道，哦。问题出现在这里了。而不是靠IDE的debug一步步去跟进。（题外话，啰嗦了。）。。。相信lz只要出现为空就直接进行错误处理，所谓的处理就是直接把线程干掉。。。囧。。。
至于第二点，我不知道lz是基于客户的善良，还是基于客户就是自己，居然假设“用户上传的数据都是合法的”，对于编程人员，这种假设是最致命的，无论是从设计还是编码，因为你根本就无法完全代表得了客户的所有操作，其实这也证明了上面的看法，lz的程序对于异常处理不够健壮。可能编写的时候，就只考虑了正常输入状态，而没有考虑非正常输入状态。所以在设计或者编码时，最好不要假设客户怎样怎样。如果真的假设了，请拿出能支撑着假设的数据。上面的，你假设上传的数据是合法的，你自己问一下，如果说服老板或者客户你的这个假设是成立的（请客户保证每次输入都是合法的?）你的假设应该是这样的：上传时程序已经对数据经过了严密的验证，数据基本保证符合格式（对不起，意外永远都会出现），后面的程序获取的数据都是合法的。如何证明后面的程序获取数据是合法的，把验证的程序拿出来，这就是证明的。当然，验证程序不够严谨，或者有些没有加入验证程序，这是另外一方面的。毕竟也有人会追问：你如何证明你的验证程序的准确率，有没有验证。。
最后一点，从安全性来说，数据至少是得经过验证的。经过验证的数据，至少能过滤掉已知的潜在危险。
对于lz的问题，除非是用户上传的数据不重要，不然都是要经过数据验证的.