yao_h: Liskov好遠目的法則～

我想應該是因為。若 父類別 是 Runtime,

子類別是 Checked。當 throws 父類別被宣告而又在實作中丟出子類別。compiler 不知該不該讓他過。

yao_h: BS for bull...??

yao_h: 哪個假設? 其實我不太懂 Liskov代換原則 和 Exception 的關係?

如果讓 Exception 加上 method boolean isCheck() 並可以 overwrite 不知會如何?

yao_h: 所以我一直覺得 Liskov = polymorphism 不知道有沒有誤 XD

原本的api若設計成使用runtimeException就是希望不要check吧，這算是強制的

yao_h: 我也是這麼想的，exception就是意外，意外在該處理的地方處理就好了

我不覺得 Checked 是壞事啊。

用 Checked annotation 是不錯

問題所在應該是 假設 父類別是 Runtime 子類別是 Checked。若程式中丟出子類別卻宣告 throws 父類別。用到這個 method 的人就避開了 Checked 檢察，可以不用 catch 了。

反過來說，假設 父類別是 Runtime 子類別是 Checked。若程式中丟出子類別卻宣告 throws 父類別。用到這個 method 的人還是得 catch。

我一開始是疑惑 java 為何要這樣做，所以提出若不是這種架構會如何。

第一篇的意思是，為何要讓 RuntimeException 繼承 Exception ? 導致了 父子類別不能改變它是不是 checked 的行為。

我猜問題在於exceptions應該是covariance 還是contravariance。Castagna有一篇著名的論文在討論這個，不過沒有好好看過。

目前我的作法會是這樣。Exception 預設都是 runtime。少數 checked Exception 統統寫成 final 不准繼承。

其實沒什麼關係。和我以前寫過傾向扁平結構的 Exception 有關。