Andrzej Bialecki wrote:
What is interesting is that javac didn't catch it either... strange. I need to read a good book on Java basics, it seems. ;)
When you implement a method you only need to declare those exceptions that can actually be thrown. But you then also narrow the set of exceptions which can be thrown by subclasses.
It makes sense also to add the throws clause to configure, I think, as Darek suggested in another post.
This is a larger change, since it is not already in the interface. All places that call this method will need to be changed to handle whatever is thrown.
What exception should this throw? IOException is tempting, since most calling code probably already handles that, but configure() isn't really an io-related operation. One can always throw RuntimeException with no declaration. Or we could define a new ConfigurationException, thrown by both Configurable.setConf() and JobConfigurable.configure().
Are there cases where we need to automatically distinguish between a configuration problem and other problems? If so, then we should probably add this new exception. But if we don't have examples of such, we might just stick with RuntimeException for now.
Doug
