用Java写的EE项目,web层使用穷人专用的spring MVC。
处理controller获得的request
有这么一句:

if (request.getParameter("action").equals("remove")) {
//we do action remove here
}

if (request.getParameter("action").equals("insert")) {
//we do action insert here
}


//其它的model处理

保存刷新一下页面,tomcat马上送给在下一个异常,
细一看,原来还是传说的中NullPointer,没办法,如果用户没有POST任何action过来,controller就死掉。
这说明,一味减少代码行数不是好习惯,应该先把action取出,并且验证其引用非null才是robust的程序。
但是区区转念又想,如果多个非null判定,程序一定会多缩进一层了,这么简单的逻辑,不至于吧~~~
忽然想起《Effective Java》中关于equals的一个描述,任意Object与null不equals(注意,不是null与任意Object非equals喔~呵呵)
于是有了下面这段改进的代码:
String action = request.getParameter("action");

if ("remove".equals(action)) ...{
//we do action remove here
}

if ("insert".equals(action)) ...{
//we do action insert here
}

//其它的model处理
妙在String的字面表达式编译后是一个Object,而反过来的null却不能用.equals的解引用。
其结果是代码更加好看了些~~
处理controller获得的request
有这么一句:













保存刷新一下页面,tomcat马上送给在下一个异常,
细一看,原来还是传说的中NullPointer,没办法,如果用户没有POST任何action过来,controller就死掉。
这说明,一味减少代码行数不是好习惯,应该先把action取出,并且验证其引用非null才是robust的程序。
但是区区转念又想,如果多个非null判定,程序一定会多缩进一层了,这么简单的逻辑,不至于吧~~~
忽然想起《Effective Java》中关于equals的一个描述,任意Object与null不equals(注意,不是null与任意Object非equals喔~呵呵)
于是有了下面这段改进的代码:











妙在String的字面表达式编译后是一个Object,而反过来的null却不能用.equals的解引用。
其结果是代码更加好看了些~~