----- "Gilles Sadowski" <gil...@harfang.homelinux.org> a écrit :
> Hello. > > > >> So go ahead with the change, removing the throws from the > declaration but keeping the javadoc as suggested previously. > > > > > > Again, what is it that you try to convey by specifying a single > exception in > > > the Javadoc? Any unchecked exception can be thrown from a class > that > > > implement the interface. > > > If the user code doesn't care that the evaluation fails, it should > catch > > > everything and continue. Alternatively, if it cannot continue, it > should let > > > the exception propagate. In either case, there isn't any useful > information > > > from a Javadoc "@throws" tag: We already know that unchecked > exceptions can > > > arise. > > > > I don't know if it's relevant here, but it's standard practice in > lots > > of code I've seen to document unchecked exceptions in the @throws > > block if your code explicitly throws it. > > This would be the minimum, but it seems that CM tries to be better in > that > it aims at also documenting the exceptions thrown from the called > code. No. We try to explain what the user could throw or rather provide guidelines on what to throw. > Of course it is more work on the part of the developer and also more > difficult do check for consistency when reading the code (short of > following > all the calls). Yes, and it what I like in checked exception, but I will not come back to this discussion, now we use unchecked exception, so we document them. Luc > > > However I would not put this > > tag on the interface method declaration, because maybe some > > implementation doesn't throw that exception. [...] > > +1 > > > Best, > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
