commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox
Date Tue, 01 Mar 2011 15:55:49 GMT
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.
What's the best way to handle that situation?
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 <sebbaz@gmail.com> wrote:
> On 1 March 2011 08:00, Jörg Schaible <joerg.schaible@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message