But, i do not like the idea of cathing a NumberFormatException to throw another exception.
Why not? I think this is perfectly valid. You have made a decision to throw an exception if the provided value is invalid. As long as you are willing to justify that original decision, the decision to wrap the NumberFormatException in an IllegalConfigurationException (or a subclass of it) is perfectly reasonable to me. It will make future additional data validation easier - your clients are already catching the nice generic exception, rather than trying to catch the multitude of different exceptions that you might later want.
It would be ideal if Integer class had a validating method
Not really - it tends to create cluttered code, and it tends to make your normal processing and your error handling all intertwine:
I prefer the second option (although I will entertain arguments against the trinomial expression ) Regards, Andrew
Im having a wrapper around the properties file (No Phil.. this onez tooo simple)
I have still such a one, a sort of fa�ade which combines Properties and access to a file. Your solution is 100% OK IMO (and what I called "settings" is a different story). I agree with Andrew about catching NumberFormatException the way you do. But I hesitate about what to do inside the catch. As me, in case the file doesn't exist (or the key was manually deleted from the file), you return the default value. In case the key exists but cannot be converted, you throw your IllegalConfigurationException. In comparison, I simply log the conversion issue at the WARNING level, and return the default value as if it was not found. I suppose that both options are defendable. Best, Phil.
Joined: Jun 24, 2003
Thanks Andrew and Phil... I was tied with some other work for a few days. Back on this again now.... Dushy