> From: Stephen McConnell [mailto:[EMAIL PROTECTED]] > > Leo Sutic wrote: > > > > > > >>From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > >> > >>void addLoggerListener( final LoggerListener listener ) > >> throws java.util.TooManyListenersException() > >>{ > >> if ( null == m_loggerListener ) > >> { > >> m_loggerListener = listener; > >> } > >> else > >> { > >> throw new java.util.TooManyListenersException(); > >> } > >>} > >> > >> > > > > +1 > > > > > > > >>* Easy to do, does not change functionality > >>* Clearer contract, although it forces client code to do exception > >> handling for the listener. > >>* No future API changes other than the removal of the declared > >> > >> > >exception > > > >Will result in compilation errors. Given a: > > > >try { > > x.addLoggerListener (this); > >} catch (TooManyListenersException tmle) { > > // Do nothing > >} > > > >if addLoggerListener (this) doesn't throw a > TooManyListenersException, > >javac will complain that "TooManyListenersException not thrown in > >corresponding try clause". > > > > But the proposed implementation DOES declare and can > potentially throw a > TooManyListenersException. I don't get the issue here. I must be > missing something (seems to be a habbit lately) - please explain.
I think you missed this part of the alternative I voted +1 for: * No future API changes other than the removal of the declared exception So while it *does* declare and can potentially throw an exception, future versions *won't*. And the removal of the declaration will result in compilation errors. So the options are these: 1. Keep the exception declared, even though it is never thrown. 2. Remove the exception. Since we should keep the necessity of try/catch to a minimum, I figure people can live with a RuntimeException potentially being thrown until we can get true multicast functionality in. /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
