先举个例子
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,没有判空,则很有可能导致异常
kotlin で書きます。
この問題は、まずインターフェイスの定義にあると思います。
インターフェースが明確に定義されており、null を返さない場合は、null 戻り値の場合を処理する必要はありません。それ以外の場合は、対処する必要があります。
問題が発生した場合は、相手にバグを報告し、相手に修正を依頼することができます。
明確な定義がない場合、インターフェースプロバイダーが当社のものではない場合、または相手が問題を抱えていてそれを時間内に修正できない場合は、自分で防御的なコードを作成するしかありません。また、インターフェイスを独自の側でラップして、null が返されないようにすることもできます。
タイトルを読んだだけではっきりとわかりますが、たとえ初期段階でインターフェース定義が標準化され、透過的であったとしても、フォールトトレランスと例外処理を行わないのであれば、信じてください。最後に泣くのはあなたです~~
これはインターフェースであるため、インターフェースプロバイダーはパラメーターと戻り値の明確な説明を提供する必要があります。これはインターフェースプロバイダーにとって常識です。それが不可能な場合は、どうすればよいかを知っておく必要があります。
インターフェイスの定義では、null が返されるタイミングと、null を返すことが何を意味するかを明確に記述する必要があります。
あなたが明確にしない場合は、他の人に明確にしてもらいましょう。それが明確になったら、あとは実行するだけです。これらの指示に従っても問題が解決しない場合は、通常は相手側の問題であるため、修正するように依頼してください。