commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 16283] - Inproper use of Exception
Date Sun, 02 Feb 2003 04:07:37 GMT
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

craig.mcclanahan@sun.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From craig.mcclanahan@sun.com  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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message