クラスライブラリ関数設計における哲学について

クラスライブラリの多くの関数の設計は巧みで、今でも彼らの設計哲学がどのようなものかを体得しています.例えばLinkedListについて、中には関数があります.

public E getFirst() {
	if (size==0)
	    throw new NoSuchElementException();

	return header.next.element;
    }

最初の要素を返します.もし前にこのコードを見たことがなければ、自分で書かせてください.null値を返すかもしれませんが、クラスライブラリには異常が投げ出されています.多くのクラスライブラリの関数(remove操作など)はこのように設計されています.
よく考えてみると確かに理にかなっている.
戻りnullと放出異常は実際には2つの異なる意味であるため、放出異常は不正な操作を行ったことを示し、戻りnull値は結果が得られなかったか、値が不確定であることを示している.
ただし、例外を投げ出さず、戻り値nullで要素がないことを表すとしてもよい.しかし、これは自分という関数の本意から少し離れているため(職責駆動設計?)違和感があると思います.そして、ユーザーがこの戻り値を検査せずに使ってしまうと、後続のトラブルを引き起こす可能性があります(そうでなければ、apiでは上空値検査を加えるべきだとユーザーに伝えます).それなら、問題が発生した早期にユーザーに問題が発生したことを伝えたほうがいい.
これは断言式プログラミング(防御的プログラミング?)を思い出させ、クラスライブラリの著者は無敵と言うべきだ.
しかし、その後、いくつかの関数が困惑しました.1つ目はpeekとelement関数がヘッダ要素を取得していますが、なぜ2つのバージョン(Dequeを実装する2つのインタフェースを上書きするためだけなのか?)を作成し、1つは異常を投げ、もう1つはnull値を返します.そしてpeekFirst...
削除面ではpollやremove()などがありますが、同様にこの問題で、めまいがします...