http://bugzilla.wpkg.org/show_bug.cgi?id=175 Rainer Meier <r.meier at wpkg.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |r.meier at wpkg.org Resolution| |WONTFIX --- Comment #1 from Rainer Meier <r.meier at wpkg.org> 2009-10-04 15:21:11 --- Hi Simon, It's true that this method returns true/ralse but in no place where it is currently used it is required to check the return value. The function returns false only in case the node could not be removed from the settings node which means it is not part of the current settings (wpkg.xml). As the intention of calling this method is to remove the package from settings it is successful in any case: - case 1: setting node exists and has been removed, return value true - case 2: setting node does not exist and does not need to be removed, return value false In both cases the state after calling the method is the same: The setting node is not part of wpkg.xml (or not any more). So in all cases where removeSettingsNode is currently used the action to be performed is done. So I don't see a reason to introduce some code to print some useless debug messages even if the return value of the method is completely irrelevant. More over on line 614 for example it will enter this area only if the settings node exists (see line 610) and therefore the return value of removeSettings node can only be true. And even if it would be false it would not matter (see above). So personally I don't see a reason to insert some bloat code to catch events never happening and confuse users by useless output messages. For example in the removePackage function removeSettingNode is called just to make sure the node is not part of the settings any more (I don't care if it was before, I just want it to be removed after I call the function). So checking the return value would be useful only in case I care about the return result. I.e. I have no clue if the node to be removed is part of the settings file at this time and I want to know if it has been before or not. But this is not the case for any of the calls currently used. By the way in case of failure or unexpected error an exception will be thrown and this will of course trigger error handling. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. |