By your reasoning, every different subtype would have its own class: IORuntimeException TextRuntimeException SQLRuntimeException :
I've only got one:
RuntimeException
:-)
On Thursday, Aug 14, 2003, at 17:37 Europe/London, Berin Loritsch wrote:
Alex Blewitt wrote:
(*) Yes, you could argue that it's a bad API, and that IOException should be added to the throws clause. But particularly, when you're dealing with an interface (e.g. java.util.Iterator) or an abstract super-type (java.util.AbstractTreeModel) you don't often have the ability to change the supertype method definition ...
Just create an IORuntimeException that can be caught that explicitly holds the parent IOException....
THat approach is a documented pattern (can't remember where I've seen it though). I still prefer a typed exception to a generic one.
Absolutely, and I was never advocating RuntimeExceptions in place of Exceptions. I was pointing out there are some places where you /cannot/ use Exception, and you're stuck with RuntimeExceptions.
So, in order of decreasing preferences:
JavaSubclassOfException -> MyOwnSubclassOfException -> JavaSubclassOfRuntimeException -> MyOwnSubclassOfRuntimeException -> RuntimeException/NullPointerException
:-)
