需要写一个方法,把json数据转换成list集合数据
public static List jsonToBean(String data, Object bean) {
List list = new ArrayList();
try {
JSONArray array;
array = new JSONArray(data);
for (int i = 0; i array.length(); i++) {
Object toBean = getBean(bean);
JSONObject ob = new JSONObject();
ob = (JSONObject) array.get(i);
toBean = jsonStrToBean(ob, toBean);
list.add(toBean);
}
return list;
} catch (JSONException e) {
Object obj = null;
JSONObject jsonObj = new JSONObject(data);
toBean = jsonStrToBean(jsonObj, toBean);
} catch (JSONException e1) {
log.error("Error covert String to JSONObject", e);
e1.printStackTrace();
e.printStackTrace();
log.error("Error covert String to JSONArray", e);
} catch (SecurityException e) {
很多朋友可能知道Go语言的优势在哪,却不知道Go语言适合用于哪些地方.
①.0、 Tsuru：开源的PAAS平台,和SAE实现的功能一模一样.
以上的就是关于go语言能做什么的内容介绍了.
单纯数据运算的话,Go语言执行效率要跟高于PHP. Go语言更偏向于工程学,体积大, 逻辑简单, 有一定运算量, 不适合处理业务. php适合做逻辑.
这个问题说来话长,我先表达一下我的观点,Go语言从语法层面提供区分错误和异常的机制是很好的做法,比自己用单个返回值做值判断要方便很多.
上面看到很多知乎大牛把异常和错误混在一起说,有认为Go没有异常机制的,有认为Go纯粹只有异常机制的,我觉得这些观点都太片面了.
具体对于错误和异常的讨论,我转发一下前阵子写的一篇日志抛砖引玉吧.
============================
最近连续遇到朋友问我项目里错误和异常管理的事情,之前也多次跟团队强调过错误和异常管理的一些概念,所以趁今天有动力就赶紧写一篇Go语言项目错误和异常管理的经验分享.
首先我们要理清：什么是错误、什么是异常、为什么需要管理.然后才是怎样管理.
错误和异常从语言机制上面讲,就是error和panic的区别,放到别的语言也一样,别的语言没有error类型,但是有错误码之类的,没有panic,但是有throw之类的.
在语言层面它们是两种概念,导致的是两种不同的结果.如果程序遇到错误不处理,那么可能进一步的产生业务上的错误,比如给用户多扣钱了,或者进一步产生了异常；如果程序遇到异常不处理,那么结果就是进程异常退出.
在项目里面是不是应该处理所有的错误情况和捕捉所有的异常呢?我只能说,你可以这么做,但是估计效果不会太好.我的理由是：
如果所有东西都处理和记录,那么重要信息可能被淹没在信息的海洋里.
不应该处理的错误被处理了,很容易导出BUG暴露不出来,直到出现更严重错误的时候才暴露出问题,到时候排查就很困难了,因为已经不是错误的第一现场.
所以错误和异常最好能按一定的规则进行分类和管理,在第一时间能暴露错误和还原现场.
对于错误处理,Erlang有一个很好的概念叫速错,就是有错误第一时间暴露它.我们的项目从Erlang到Go一直是沿用这一设计原则.但是应用这个原则的前提是先得区分错误和异常这两个概念.
错误和异常上面已经提到了,从语言机制层面比较容易区分它们,但是语言取决于人为,什么情况下用错误表达,什么情况下用异常表达,就得有一套规则,否则很容易出现全部靠异常来做错误处理的情况,似乎Java项目特别容易出现这样的设计.
这里我先假想有这样一个业务：游戏粉丝通过购买按钮,用铜钱购买宝石.
在这种结构下,铜钱不足就变成了业务逻辑范围内的一种失败情况,但不能提升为异常,否则铜钱不足的用户一点购买按钮都会出错掉线.
所以,异常和错误在不同程序结构下是互相转换的,我们没办法一句话的给所有类型所有结构的程序一个统一的异常和错误分类规则.
所以我们可以这样来归类异常和错误：不会终止程序逻辑运行的归类为错误,会终止程序逻辑运行的归类为异常.
错误和异常的分类需要通过一定的思维训练来强化分类能力,就类似于面向对象的设计方式一样的,技术实现就摆在那边,但是要用好需要不断的思维训练不断的归类和总结,以上提到的归类方式希望可以作为一个参考,期待大家能发现更多更有效的归类方式.
此时此刻呢我们讲一下速错和Go语言里面怎么做到速错.
速错我最早接触是在做的时候就体验到的,当然跟Erlang的速错不完全一致,那时候也没有那么高大上的一个名字,但是对待异常的理念是一样的.
在.NET项目开发的时候,有经验的程序员都应该知道,不能随便re-throw,就是catch错误再抛出,原因是异常的第一现场会被破坏,堆栈跟踪信息会丢失,因为外部最后拿到异常的堆栈跟踪信息,是最后那次throw的异常的堆栈跟踪信息；其次,不能随便try catch,随便catch很容易导出异常暴露不出来,升级为更严重的业务漏洞.
到了Erlang时期,大家学到了速错概念,简单来讲就是：让它挂.只有挂了你才会第一时间知道错误,但是Erlang的挂,只是Erlang进程的异常退出,不会导致整个Erlang节点退出,所以它挂的影响层面比较低.
在Go语言项目中,虽然有类似Erlang进程的Goroutine,但是Goroutine如果panic了,并且没有recover,那么整个Go进程就会异常退出.所以我们在Go语言项目中要应用速错的设计理念,就要对Goroutine做一定的管理.
第一类Goroutine典型的有：处理各个粉丝请求的Goroutine,因为每个粉丝连接各自有一个Goroutine,所以挂掉了只会影响单个粉丝,不会影响整体业务进行.
第二类Goroutine典型的有：数据库同步用的Goroutine,如果它挂了,数据就无法同步到数据库,游戏如果继续运行下去只会导致数据回档,还不如让整个游戏都异常退出.
这样一分类,就可以比较清楚哪些Goroutine该做recover处理,哪些不该做recover处理了.
为此,我们还特地设计了一个库,用来格式化输出堆栈跟踪信息和对象信息,项目地址：funny/debug - GitHub
通篇写下来发现比我预期的长很多,所以这里我做一下归纳总结,帮组大家理解这篇文章所要表达的：
错误和异常需要分类和管理,不能一概而论
错误和异常的分类可以以是否终止业务过程作为标准
错误是业务过程的一部分,异常不是
不要随便捕获异常,更不要随便捕获再重新抛出异常
Go语言项目需要把Goroutine分为两类,区别处理异常
在捕获到异常时,需要尽可能的保留第一现场的关键数据
以上仅为一家之言,抛砖引玉,希望大家如果觉得本站发布的文章不错,请转发分享给您身边的朋友,您的支持是我们最大的动力.
Go 语言是静态类型语言,虽然它也可以表现出动态类型,但是使用一个嵌套的 map[string]interface{} 在那里乱叫会让代码变得特别丑.通过掌握语言的静态特性,我们可以做的更好.
通过同一通道交换多种信息的时候,我们经常需要 JSON 具有动态的,或者更合适的参数内容.首先,让我们来讨论一下消息封装(message envelopes),JSON 今天这一节看起来就像这样：
通过 interface{},我们可以很容易的将数据结构编码成为独立封装的,具有多种类型的消息体的 JSON 数据.为了生成下面的 JSON ：
我们可以使用这些 Go 类型：
输出的结果是：
这些并没有什么特殊的.
如果你想将上面的 JSON 对象解析成为一个 Envelope 类型的对象,最终你会将 Msg 字段解析成为一个 map[string]interface{}. 这种方式不是很好用,会使你后悔你的选择.
输出：
就像前面说的,我推荐修改 Envelope 类型,就像这样：
json.RawMessage 非常有用,它可以让你延迟解析相应的 JSON 数据.它会将未处理的数据存储为 []byte.
这种方式可以让你显式控制 Msg 的解析.从而延迟到获取到 Type 的值之后,依据 Type 的值进行解析.这种方式不好的地方在于你需要先明确解析 Msg,或者你需要单独分为 EnvelopeIn 和 EnvelopeOut 两种类型,其中 EnvelopeOut 仍然有 Msg interface{}.
那么如何将上述两者好的一面结合起来呢?通过在 interface{} 字段中放入 *json.RawMessage!
虽然我极其推荐你将动态可变的部分放在一个单独的 key 下面,但是有时你可能需要处理一些预先存在的数据,它们并没有用这样的方式进行格式化.
如果可以的话,请使用文章前面提到的风格.
我们可以通过解析两次数据的方式来解决.
dynamite