Hi Benedikt! don't get crazy with Assertions.* methods, they are just internal shortcuts!
OTOH I would focus the attention on public methods to invoke methods via reflection, that would be really more useful. Thanks for your efforts! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Jan 25, 2012 at 9:53 PM, Benedikt Ritter <b...@systemoutprintln.de> wrote: > Hi, > > I'm refactoring AssertionsTest to match the discussed best practices. I > wrote a test method for checkArgument(boolean Argument, String > errorTemplate, Object.. errorArgs): > > @Test( expected = NullPointerException.class ) > public void checkArgumentFalseStringNull() > { > checkArgument( false, ERROR_MSG, (Object[]) null ); > } > > The javadoc for checkArgument is: > @throws NullPointerException if the check fails and either {@code > errorMessageTemplate} or {@code errorMessageArgs} is null (don't let > this happen) > > but when I execute the test, it fails because I'm getting an > IllegalStateException (instead of the expected NPE). Although this is > expected if false is passed in, it violates the contract described in the > javadoc. I'm not sure what to do now. I could either change the > implementation of checkArgument to throw the correct exception if errorArgs > is null or change the javadoc (remove the second part of the throws > declaration). > I would prefer the latter. But then one thing has to be paid attention to: > If we call checkArgument(false, ERROR_MSG) and ERROR_MSG contains any > placeholders ("%s") and there are no errorArgs given, a > java.util.MissingArgumentFormatException will be thrown. So we would have to > deal with that. > > Any thoughts? > > All the best > Benedikt > > PS: this also applies to checkState(boolean state, String errorTemplate, > Object... errorArgs) > > --------------------------------------------------------------------- > 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
