commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Heger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CONFIGURATION-277) AbstractConfiguration should handle UnsupportedOperationExceptions in Iterator.remove() gracefully
Date Fri, 01 Jun 2007 20:47:16 GMT

    [ https://issues.apache.org/jira/browse/CONFIGURATION-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500846
] 

Oliver Heger commented on CONFIGURATION-277:
--------------------------------------------

Well, clearProperty() is already invoked in the loop as a fall back if removing through the
iterator does not work. So for an iterator that does not support the remove() method there
are the following possibilities:
(1) If it operates on a disjunct set of keys, clearProperty() will work and everything is
fine.
(2) If it is affected by clearProperty(), a ConcurrentModificationException will be thrown.
In this case, we have basically transformed the UnsupportedOperationException into another
one, so we have not made things worse.

In case of (2) the implementor of the derived Configuration class is forced to write a custom
clear() implementation. In case of (1) we have made the implementor's life a bit easier. So
we would have a certain gain.

> AbstractConfiguration should handle UnsupportedOperationExceptions in Iterator.remove()
gracefully
> --------------------------------------------------------------------------------------------------
>
>                 Key: CONFIGURATION-277
>                 URL: https://issues.apache.org/jira/browse/CONFIGURATION-277
>             Project: Commons Configuration
>          Issue Type: Bug
>    Affects Versions: 1.4
>            Reporter: Michael Rudolf
>
> Hi,
> In AbstractConfiguration method clear() on line 533 (see code below) a possible UnsupportedOperationException
is not caught resulting in the malfunctioning of the whole method. However, the documentation
of the getKeys() method itself warns about relying on the remove() method of interface Iterator.
The clear() method should not propagate that exception, it should catch it and try the clearProperty(String)
approach if the remove() method is not supported.
>             Iterator it = getKeys();
>             while (it.hasNext())
>             {
>                 String key = (String) it.next();
>                 it.remove();                                          <------- EVIL!
>                 if (containsKey(key))
>                 {
>                     // workaround for Iterators that do not remove the property on calling
remove()
>                     clearProperty(key);
>                 }
> Best regards,
> Michael

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


Mime
View raw message