On 1 March 2011 15:55, Simone Tripodi <simonetrip...@apache.org> wrote:
> Hi Seb!
> thanks a lot for your hints too, very appreciated!
>
> Something suggests me to remove the @SuppressWarnings because
> ClassCastException are admitted, let's suppose I have the given XML:
>
> <a>
> <prop>text</prop>
> </a>
>
> that can be mapped to
>
> class A {
> String prop;
> }
>
> if a user tries to map to a different type
>
> B b = digester.parse("<a><prop>text</prop></a>");
>
> An exception has to be thrown.
It will be thrown with the generic fix, because the compiler adds a
cast to the parse return.
However, there is no obvious casting in the above code, so the user
may be puzzled by the ClassCastException.
> What's the best way to handle that situation?
I think the problem is that parse is not really a generic method, and
Java does not make the target class available to the method.
If you changed the API to add a Class parameter then you could do the
check in the parse method.
But that might be just as awkward to use.
It is obviously nicer to read if the compiler inserts the casts
automatically, but the downside is that CCEs can occur when you least
expect them.
In the sample code, it will happen immediately, but the instance could
be stored in a collection and then the CCE might not occur until much
later.
Maybe one solution would be to allow the autocasting, but provide a
big warning in the Javadoc that it may result in CCEs at any time.
For those who don't want to take this risk, there would need to be
another version which guaranteed the correct class - or an Exception
if that's not possible.
> Many thanks in advance, have a nice day!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Mar 1, 2011 at 4:04 PM, sebb <seb...@gmail.com> wrote:
>> On 1 March 2011 08:00, Jörg Schaible <joerg.schai...@scalaris.com> wrote:
>>> Hi Simone,
>>>
>>> Simone Tripodi wrote:
>>>
>>> [snip]
>>>
>>>
>>>> @SuppressWarnings("unchecked")
>>>> public <T> T parse(InputSource input, Class<T> returnedType) throws
>>>> IOException, SAXException {
>>>> .
>>>> .
>>>> .
>>>> return returnedType.cast(this.root);
>>>> }
>>>
>>> It would be nice, if we can start to avoid such method global suppressions,
>>> because it hides possibly unwanted stuff. You can always assign the
>>> annotation directly to a variable instead:
>>>
>>> @SuppressWarnings("unchecked")
>>> T t = returnedType.cast(this.root);
>>> return t;
>>
>> I would go a bit further and say that @SuppressWarnings should not be
>> used unless you can prove that the cast is always valid (as may well
>> be the case here - I've not checked), and that this should be
>> documented in a // comment on the annotation, e.g.
>>
>> @SuppressWarnings("unchecked") // OK because etc.
>>
>> Otherwise, the annotation effectively gives the compiler permission to
>> cause a ClassCastException somewhere else at some point in the future.
>>
>> As with many forms of suppression, the risk is that there will be a
>> bad reaction later ...
>>
>>
>>> - Jörg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
