DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16283>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16283 Inproper use of Exception [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WONTFIX ------- Additional Comments From [EMAIL PROTECTED] 2003-02-02 04:07 ------- Regarding your deprecation proposal, it's not technically feasible to change the following: /** * Documentation for PoolableConnectionFactory ... */ public PoolableConnectionFactory(ConnectionFactory connFactory, ObjectPool pool, KeyedObjectPoolFactory stmtPoolFactory, String validationQuery, boolean defaultReadOnly, boolean defaultAutoCommit) throws Exception; into the following: /** * Documentation for PoolableConnectionFactory ... * * @deprecated Use the following version instead */ public PoolableConnectionFactory(ConnectionFactory connFactory, ObjectPool pool, KeyedObjectPoolFactory stmtPoolFactory, String validationQuery, boolean defaultReadOnly, boolean defaultAutoCommit) throws Exception; /** * Documentation for PoolableConnectionFactory ... */ public PoolableConnectionFactory(ConnectionFactory connFactory, ObjectPool pool, KeyedObjectPoolFactory stmtPoolFactory, String validationQuery, boolean defaultReadOnly, boolean defaultAutoCommit) throws SomeSpecificException; because the compiler will complain about duplicate method signatures. The only way to actually make the change is to eliminate the old signature, which breaks every application signature that used the old approach (unless SomeSpecificException was a subclass of Exception, which doesn't really accomplish your objective anyway; it sounds like you would prefer something based on a RuntimeException so that would not require a try/catch block in the calling code). Maintaining backwards compatibility, especially within a major version number, is a core value of most Jakarta projects -- and especially so in jakarta-commons. Making a change like the one you suggest would be very disruptive. And you ***still*** have not described what you think "an exception appropriate for the error that occurred" in this particular constructor, or for any other specific case. Inded, it is hard to conceive of what such an exception would be, given that the commons-pool APIs define a generic framework for building pools, and there is no way to come up with a specific exception class that will cover all possibilities. At best, you could create a general PoolException that would need to be subclassed by pool implementations -- and that doesn't really add any value over java.lang.Exception. As to your assertion about "bad", I've only been a professional software developer for a short while (about to start my 29th year of getting paid for it, and almost half of that in O-O languages :-), but one thing I have definitely learned is that statements from people who make absolute judgements, and state them as facts rather than opinions, and offer no specific evidence or collaboration, should definitely be taken with a large grain of salt. Get off your high horse, please, and make a *specific* proposal for the API signatures you don't like. And, the best place to do that is on the COMMONS-DEV mailing list, where you can endeavor to convince the other developers on the pool project to share your views. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
