This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Anything can throw a RuntimeException at any time--no restrictions are necessary, nor is it necessary to declare it in the "throws".
If you were able to declare additional checked exceptions then you would no longer be following the "contract" of the original method--code that calls it shouldn't have to change if it starts using a subclass implementation.
Like it cant declare any new or broader checked exceptions
Because if you create an instance of class B which extends A, store it in a reference to A, and then call B's overridden methods, the compiler would not be able to recognize that the overridden functions in B are throwing the new or broader exceptions.
Joined: Jun 15, 2010
Why dont the above rules apply for Runtime Exceptions?
From a design perspective, you should also worry about runtime exceptions.
Just because the compiler allows something does not mean that it should be
done. For example, consider invalid downcasts.
Think about code already in service that uses the method you want to override;
a method that throws MyException. During program checkout, it was verified that
MyException was properly handled. For the revised method, following the Is-A rule,
the catch clause that handles MyException will also handle an extension of it, if you
create one. But it may not catch a new exception type, runtime or otherwise. So you
will have broken the application error handler.
Jim ... ...
BEE MBA PMP SCJP-6
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com