Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Antonio Gallardo wrote:
Antonio Gallardo dijo:
Hi:
I also have another question. We have some exceptions that are not being throw at all, but the method declare it. Sample at line 76:
Filling the missing link :(
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/xsp/ja
va/org/apache/cocoon/components/language/markup/Logicsheet.jav
a?annotate=1.3
The constructor does not throw any of the declared Exceptions.
Can we clean up this code? There are cca 150 similar places
over the code.
In general I'm +1 for such changes, but unfortunately these are incompatible
changes! For example, if a client has a try/catch clause for such
an exception and you remove it from the list, then the client code
is not compilable anymore as the exception is not thrown inside
the block anymore.
So, I would say, let's leave them there (but I'm not opposed to remove them
:) ).
"Throws" declarations can be safely removed in the situation when method implements an interface. Interface will have exception declarations, and interface implementation might not have them if it does not need them.
Great care must be taken however about classes that can be extended, as not declaring the thrown exception from the base class or interface forbids subclasses to throw them.
An example of this can be found in o.a.c.components.ExtendedComponentSelector.initialize() where exceptions have to be wrapped in a RuntimeException because the parent class has omitted the throws clause.
In all other situations, Carsten is right - this might cause backward incompatibility. This is important for user-facing classes. Should we start marking classes as internal, like "<b>INTERNAL!!!</b>" in javadoc or some such?
+1000!
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
