On 28/06/2023 14:16, Gary Gregory wrote:
Hi All and Phil.
I haven't been that involved in Pool recently but Pool remains a key
dependency for Tomcat (via DBCP).
The main driver here was two combine keeping binary compatibility
_and_ benefit call sites of the API by _not_ having to catch Exception
or throw Exception, which clearly is an anti-pattern. Instead, call
sites should deal with domain exceptions, which they can in turn
handle. IOW, when I am using IO resources or JDBC resources, I should
expect to handle IOException and JDBCException, not Exception, so by
extension (more on this below), I would expect to handle the same
kinds of exceptions when I am pooling those kinds of resources.
I understand the aim and I am generally in favour of simplification.
However, Pool still throws unchecked exceptions (NoSuchElementException
and IllegalStateException, possibly others) during normal operations and
I think that significantly undermines what this change is trying to achieve.
<snip/>
Question: If we were to design Pool from scratch today, would we
create APIs with checked or unchecked exceptions?
For Pool I have a slight preference for using checked exceptions
throughout but I agree that is a larger design change that needs a wider
discussion.
<snip/>
I did not get the points Phil is trying to make in his examples, I'm
not sure they are valid. OTOH, the unit tests do show using the APIs
typed with different types of exceptions. Sure, there might be
adjustments to make, but I don't see the flaws you seem to think are
there. WRT to source changes, I welcome cleaning up my call sites! The
debate is valid and I hope we have interesting replies to this thread.
My main concern is not whether Pool should make this change (I think the
change makes sense) but when Pool should make this change and alongside
what other changes.
At this point I'm not convinced the cost / benefit of the change in a
minor release stacks up.
I suspect very few users are simply going to replace the old JAR with
the new one and take advantage of binary compatibility. They are going
to update their build dependencies and then compilation is going to
fail. I don't think users will appreciate that in a minor release
however much we tell them they are binary compatible.
To fix the compilation issues and retain existing behaviour (without
worrying about the unchecked exceptions the Pool does throw during
normal operations) they are going to have to modify their code so that E
== Exception. That is going to look like a make-work task as they will
get zero benefit from it.
I think the majority of the benefit of this changes comes if Pool also
stops throwing unchecked exceptions - as a minimum during normal pooling
operations.
I'd prefer to see this change deferred to a Pool 3.0 release preceded by
a wider discussion of the benefits of unchecked vs checked that has
started in this thread.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
