先举个例子
public Result doSomething(String balabala);
public class Result{
private Long productId;
....
}
上面接口是其他部门的程序员提供给你的。没有文档,接口没有注释。
首先,我调用这个接口,
Result result= doSomething("fuck");
调用之后,我要返回的productId再去请求其他接口,做其他一些事情。
问题来了:
对这个返回的result,你是直接result.getProductId(); 还是先判断一下,result!= null 然后再result.getProductId();那productId又是Result里的引用类型,你拿到productId要不要再productId != null
,Result还有其他的引用类型,是不是我每用一个非得判空?
可能每个人的习惯不一样,比如写那个接口,有的人是哪怕什么信息都没有返回,也返回一个空的result。有的人是如果没有信息返回就返回null。如果只要是引用类型,我都判断是否为空,是不是显得“过于谨慎”了。文档,注释也不可能规定的那么细,程序员之间的约定吧,那一个几百人的团队,难免会有不遵循约定的。你们是如何处理的?
又比如一条记录,业务上规定,productId不可能为空的,但是这条记录的插入涉及到两条sql语句,一个程序员的失误没有保证原子性,导致productId为空的记录被插入进去了。这时候,我一旦涉及到处理productId,没有判空,则很有可能导致异常
伊谢尔伦2017-04-18 09:56:07
이 문제는 먼저 인터페이스의 정의에 있다고 생각합니다.
인터페이스가 명확하게 정의되어 있고 null을 반환하지 않는 경우 null 반환 값이 있는 경우를 처리할 필요가 없습니다. 그렇지 않으면 처리해야 합니다.
문제가 발생하면 상대방에게 버그를 신고하고 상대방에게 수정을 요청할 수 있습니다.
명확한 정의가 없거나, 인터페이스 제공자가 우리 회사가 아니거나, 상대방이 문제가 있어 제때에 수정할 수 없는 경우에는 방어 코드를 직접 작성하는 수밖에 없습니다. 그리고 null이 반환되지 않도록 사용자 측에서 인터페이스를 래핑할 수 있습니다.
怪我咯2017-04-18 09:56:07
제목만 봐도 확실히 알 수 있는데, 초기에 인터페이스 정의가 표준화되고 투명하더라도 내결함성과 예외 처리를 하지 않으면 믿을 수 없습니다. 결국엔 우는 사람은 너겠지~~
高洛峰2017-04-18 09:56:07
인터페이스이기 때문에 인터페이스 제공자는 매개변수와 반환값에 대한 명확한 설명을 제공해야 합니다. 이는 인터페이스 제공자에게는 상식입니다. 그것이 가능하지 않다면 무엇을 해야 할지 알아야 합니다.
怪我咯2017-04-18 09:56:07
인터페이스 정의에서는 null이 반환되는 시기와 null 반환이 무엇을 의미하는지 명확하게 명시해야 합니다.
당신이 명확하게 밝히지 않으면 상대방이 명확하게 하도록 하세요. 명확해지면 그냥 실행하세요. 이 지침을 따른 후에도 여전히 문제가 발생하는 경우 일반적으로 상대방의 문제이므로 수정을 요청하세요.