最近入职一家新公司，第一周遇到一个人带着做项目，本来以为是带着熟悉一下业务，没想到被鄙视了。问我以前公司的时候也这么写代码？我当时比较蒙，确实不熟悉业务，于是接受了批评，表示以后一定改。
但是没过5分钟，我突然想明白了，和他去说自己的想法，得到的回复是，你现在应该适应现在，然后再改进，我说行！他说的没错，但是我觉着有些问题虽然没有明确的对错，但是会有每个人的理由。下面说一下我遇到的问题和争论的焦点。
我做的是Java EE的controller层的编码，使用的是zk框架，他们建议我在controller里对每个对象在使用之前都要做为空的判断，我觉着也有道理。但是争论的焦点在容器类和判断后的处理，我的观点是：
一、对于容器类，使用前可以不判断，我的理由是所有返回值是容器类的方法永远都不应该返回null，而是应该用空容器替代，如果返回null，那么就是方法的bug；
二、在controller层，如果判断为空了，那么就一定要做完善的处理，不能简单的用这种方式
if(some == null){
return;
}
或者
if(some != null){
dosomething;
}
for(Object o:List){
if(o==null){
continue;
}
}
及时加上log日志，这种做法我觉着还不如不做判断的方案更好，理由是，做了这种处理掩盖了错误，虽然可以能够提供所谓的稳定性，但是对于业务和将来问题的排查产生重大问题。
在controller层不做为空处理，当数据有问题时会报错误，咱们加个500的错误处理页面展示给用户，人家知道你犯错误了，会做其他处理；但是如果用上述方法掩盖了问题，虽然不会报错了，但是用户也没有得到想要的结果，而且还不知道为什么会这样。
在for循环里，做跳过处理，其实是自作主张的删除了一条记录，虽然这个是非法数据，但是我们也没有权利掩盖掉。
这样做，给我的感觉是程序员为了避免所谓的bug，给系统增加了更大的风险。不加日志会难于排查将来的系统业务问题，即使加了日志，对于用户来说也会造成困扰。
如果觉着非要处理掉所有的null，那么我觉着应该在出现null的地方给用户一个里的提示，如果没有提示，那么请不要掩盖可能的错误或者异常，因为用户有知情权，程序员不该为了所谓的稳定性，用掩耳盗铃的方式处理null，尤其是在controller层。
异常处理其实是编码过程最难的部分，如果功力不够深，就让错误尽量的暴露出来，不丢人。
从开发效率来说，从我个人的经验来说，建议在controller层尽量减少不必要的null判断，在写服务的时候写的药尽量稳定，药处理掉各种情况。
写的比较乱，欢迎看懂的朋友拍砖。本人虚心接受