其实参数解析有问题直接抛出就行了,完全不用纠结。

如果实在无法处理Integer参数,可以选择换用String,能避免很多麻烦。

经常遇到spring mvc或者jersey中传入json再转化为实体类的场景,如果其中有interger属性的变量,那么转换的时候就会遇到一些问题。

这就需要一些小技巧去解决。

一、问题场景

这个是我前段时间遇到的一个场景:

  1. 使用jersey2。
  2. mysql中id的属性为number,长度50。
  3. 然后pojo中对应的变量是id,为interger。
  4. 这时候需要在前端自定义传入一个json,json中的id是自定义的,可以随便传,想传多长传多长,想传什么传什么。

结果就遇到了以下的问题:

  1. 前端传了一个如下字符串”123abc”,结果当然是不匹配,jersey2报错json不能转化为实体类。
  2. 前端做了限制,限制为只能传数字,然后绕过前端直接请求接口,问题依然存在。
  3. 前端传了一个超长的Interger,例如”111111111111111111111111111″,这个已经超出Interger的最大长度了,还是不匹配,jersey2又报错了。
  4. 前端做了限制,限制传入的长度,然后绕过前端直接请求接口,问题依然存在。

…..等等等等。

二、遇到的问题

由此可以看出,在前端做限制是完全不靠谱的,只能在后端也加上限制。

但是问题又来了,这个jersey2报错是框架自带的错误,catch都catch不到,就算后端对interger做了限制,如果前端传的数据有问题,jersey2还是会报错。

三、解决方法

所以干脆就把这个id改成string!

然后做个null检测,做个长度限制,做个正则判断是不是纯数字,遇到的问题就少很多了。

四、总结

如果实在无法处理Integer参数,可以选择换用String,能避免很多麻烦。

那么问题来了,参数报错就报错呗,能抛出就行了,干嘛纠结怎么完全不报错…

所以写这篇文章的时候完全是脑抽了,但是String代替Integer的思路确实是值得商榷的。

发表评论

电子邮件地址不会被公开。 必填项已用*标注