I agree that it would be nice to have for 1.0, on the otherhand, don't want to rush it in!
The subclassing was only done to continue to support pre 1.4 jdk's. We actually used a jdk1.4 specific method call at one point and broke some of our users code! Until we are ready to say 1.4 or better, I'd like to keep the older stuff. It does sound like the runtime is the way to go, versus checked. At this point then, does it really matter if we are throwing a ConfigurationRuntimeException on the getters? Since something farther down will? It does seem like ConfigurationSetupException or ConfigurationInitializationException should be thrown by the various places where we know that we can have an error, like when creating the Configuration from the ConfigurationFactory. and, if the DatabaseConfiguration thinks that it may throw SQLExceptions, then it could throw a runtime ConfigurationException.. Eric > -----Original Message----- > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 22, 2004 2:45 PM > To: Jakarta Commons Developers List > Subject: RE: [Configuration] Throws ConfigurationException? > > > > Howdy, > Long message, short comments: > - A runtime exception, yes, not a checked exception. > > - Good to have for release 1.0: you wouldn't want to > introduce this kind > of behavior change from 1.0 to 1.1. > > - Why subclassing a commons-lang exception as opposed to the > normal java > RuntimeException? For pre-JDK 1.4 nesting compatability? > > Yoav Shapira > Millennium ChemInformatics > > > >-----Original Message----- > >From: Eric Pugh [mailto:[EMAIL PROTECTED] > >Sent: Thursday, January 22, 2004 6:51 AM > >To: Commons-Dev (E-mail) > >Subject: [Configuration] Throws ConfigurationException? > > > >Hi all, > > > >A while ago we discussed 1.0 requirements that are left. And at this > >point, > >all have been finished except changing the api to throw a > >ConfigurationException. > > > >Now, I am thinking about how to implement this, and am not > too keen on > the > >idea of ConfigurationException being a non runtime explicit > Exception. > >Primarily because I expect Configuration to always work, and > so when I > say: > > > > String s = Configuration.getString("my.string"); > > > >I don't want to be surrounding it with try/catch for > >ConfigurationException. > >Indeed, I know what will happen, it will join the other methods that > all > >throw Exception because if a ConfigurationException happens, there is > no > >way > >for me to deal with it, except by crashing out the app! > > > >So, if we want a ConfigurationException, why don't we make it a > extension > >of > >NestableRuntimeException (from commons-lang) and declare > that we throw > >that? > > > >Or, if we aren't really sure what the Exception handling of the 1.0 > version > >should be, then skip it (since what we have is "good enuf"), and move > to a > >release of 1.0 so we can really think about what we want. > > > >I think just throwing a ConfigurationException on everything that is > >explicit is going to make the API harder to use and force bigger > changes on > >everybodies code that wants to use it. > > > > > >Just one more thing.. Having said that about > ConfigurationException, I > was > >looking at the ConfigurationFactory and the getConfiguration() method > >throws > >an Exception. It really should throw a ConfigurationException that > extends > >NestableException, and then maybe we have ConfigurationException > extends > >NestableException and ConfigurationRuntimeException extends > >NestableRuntimeException? > > > >I really want to get to the 1.0 release of Configuration soon, > especially > >now that we have a database backed exceptions plus all the goodies in > >ConfigurationFactory! > > > >Eric > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > This e-mail, including any attachments, is a confidential > business communication, and may contain information that is > confidential, proprietary and/or privileged. This e-mail is > intended only for the individual(s) to whom it is addressed, > and may not be saved, copied, printed, disclosed or used by > anyone else. If you are not the(an) intended recipient, > please immediately delete this e-mail from your computer > system and notify the sender. Thank you. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
