You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Robert Zeigler <ro...@roxanemy.com> on 2012/02/24 01:10:04 UTC
assertions for argument checking
Hm. Just noticed this:
BeanModelSourceImpl.java:
...
public <T> BeanModel<T> create(Class<T> beanClass, boolean filterReadOnlyProperties, Messages messages)
{
assert beanClass != null;
assert messages != null;
...
Why are we using assertions to check the arguments? Even in java 6,assertions are disabled by default at runtime, and according to:
http://docs.oracle.com/javase/1.5.0/docs/guide/language/assert.html:
"Do not use assertions for argument checking in public methods.
Argument checking is typically part of the published specifications (or contract) of a method, and these specifications must be obeyed whether assertions are enabled or disabled. Another problem with using assertions for argument checking is that erroneous arguments should result in an appropriate runtime exception (such as IllegalArgumentException, IndexOutOfBoundsException, orNullPointerException). An assertion failure will not throw an appropriate exception."
This just tripped up a new user; they received an NPE in TapestryInternalUtils.defaultLabel due to the message catalog being null.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: assertions for argument checking
Posted by Ulrich Stärk <ul...@spielviel.de>.
+1 for the Defense static class.
On 24.02.2012 01:36, Howard Lewis Ship wrote:
> Wow, just when you think Java can't be any more broken, the fact that
> assertions are disabled by default hits you.
>
> Well, we could either document that you want to generally developer
> with assertions enabled, or we should bring back our old friend, the
> Defense static class.
>
> On Thu, Feb 23, 2012 at 4:10 PM, Robert Zeigler
> <ro...@roxanemy.com> wrote:
>> Hm. Just noticed this:
>>
>> BeanModelSourceImpl.java:
>> ...
>> public <T> BeanModel<T> create(Class<T> beanClass, boolean filterReadOnlyProperties, Messages messages)
>> {
>> assert beanClass != null;
>> assert messages != null;
>> ...
>>
>>
>> Why are we using assertions to check the arguments? Even in java 6,assertions are disabled by default at runtime, and according to:
>> http://docs.oracle.com/javase/1.5.0/docs/guide/language/assert.html:
>>
>> "Do not use assertions for argument checking in public methods.
>> Argument checking is typically part of the published specifications (or contract) of a method, and these specifications must be obeyed whether assertions are enabled or disabled. Another problem with using assertions for argument checking is that erroneous arguments should result in an appropriate runtime exception (such as IllegalArgumentException, IndexOutOfBoundsException, orNullPointerException). An assertion failure will not throw an appropriate exception."
>>
>> This just tripped up a new user; they received an NPE in TapestryInternalUtils.defaultLabel due to the message catalog being null.
>>
>> Robert
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: assertions for argument checking
Posted by Howard Lewis Ship <hl...@gmail.com>.
Wow, just when you think Java can't be any more broken, the fact that
assertions are disabled by default hits you.
Well, we could either document that you want to generally developer
with assertions enabled, or we should bring back our old friend, the
Defense static class.
On Thu, Feb 23, 2012 at 4:10 PM, Robert Zeigler
<ro...@roxanemy.com> wrote:
> Hm. Just noticed this:
>
> BeanModelSourceImpl.java:
> ...
> public <T> BeanModel<T> create(Class<T> beanClass, boolean filterReadOnlyProperties, Messages messages)
> {
> assert beanClass != null;
> assert messages != null;
> ...
>
>
> Why are we using assertions to check the arguments? Even in java 6,assertions are disabled by default at runtime, and according to:
> http://docs.oracle.com/javase/1.5.0/docs/guide/language/assert.html:
>
> "Do not use assertions for argument checking in public methods.
> Argument checking is typically part of the published specifications (or contract) of a method, and these specifications must be obeyed whether assertions are enabled or disabled. Another problem with using assertions for argument checking is that erroneous arguments should result in an appropriate runtime exception (such as IllegalArgumentException, IndexOutOfBoundsException, orNullPointerException). An assertion failure will not throw an appropriate exception."
>
> This just tripped up a new user; they received an NPE in TapestryInternalUtils.defaultLabel due to the message catalog being null.
>
> Robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org