以前也有過這個疑問，正好發(fā)表一下自己的看法。
首先，以“-able”結尾大多數(shù)時候確實用來表示接口，但說到底這不過是一個約定，而不是語法要求。把它當成95%但不要當成100%。類似的還有以反寫的域名作為包名、類名采用駝峰結構且以大寫字母開頭、常量全大寫，這些都是約定，不遵守約定的不多，尤其是在正式項目中，但是也確實都存在。
其次，你會發(fā)現(xiàn)Java的異常機制里面是沒有接口的，它的頂層類就是Throwable。也就是說，你要定義一個異常類，就必須繼承另一個異常類，因為catch子句要求它必須捕獲一個異常，而不是任意對象（Javascript就沒有這個要求，因此你可以捕獲任何對象作為異常）。
既然自定義的異常必須要繼承另一個異常類，那么它就不能再繼承別的類，這樣就在很大程度上限制了異常類的用途，從而更有利于開發(fā)設計良好的程序。
比如，假設Throwable是一個接口，那么任何一個類都可以實現(xiàn)它，然后作為異常用catch來捕獲，這就有點類似Javascript的情況了，違反了單一職責原則。所以現(xiàn)在Javascript也建議程序員盡量用專門的異常對象，而不是字符串，這樣會讓程序更明確。
當然了，如果你愿意，還是可以突破這個限制，比如定義一個異常類，繼承Throwable的同時也實現(xiàn)其他接口，這樣這個異常類也可以當成其他類來使用。只是一般沒人這么干，因為繼承接口就要實現(xiàn)接口中的所有方法，那么既然要實現(xiàn)所有方法，為什么不重新定義一個更合適的類來實現(xiàn)呢，重新定義還可以繼承某個骨架抽象類，減少子類中的代碼量，何樂而不為呢是不是？反過來Throwable如果是一個接口就沒有這種隱含的約束，可能就會有大量的人這么干。
至于Throwable是否有狀態(tài)的，應該是其次的原因，或者說是將Throwable定義成一個類所帶來的額外好處。因為如果只是因為狀態(tài)原因的話，Java當時完全可以先定義一個Throwable接口，里面有getMessage()等方法，然后再定義一個抽象類或具體類來實現(xiàn)這個接口（這個類可能就是現(xiàn)在的Exception來充當了）。畢竟JDK里面已經有太多這樣的案例了，比如集合、流、JDBC、……
                            

谷歌搜whythrowableisaclassnotinterface即可以及答案在這個問題的第二個回答簡單來說就是Throwable被設計成了一定是有狀態(tài)的，所以就不能是interface了