Hello. [Sorry to continue a discussion that should probably go in its own thread.]
Le jeu. 29 juin 2023 à 11:43, Mark Thomas <ma...@apache.org> a écrit : > > 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. Looking at a commit [1] related to POOL-269 [2], a signature like void addObject(K key) throws E, IllegalStateException, UnsupportedOperationException; does not qualify as "simple". 1. Unchecked exceptions should not be referred to in the "throws" clause. 2. What is the advantage of a parameterized exception[3] over a common one (say "PoolException"), and use the standard JDK mechanism of storing more details in a "cause"[4] ? 3. Unchecked exceptions can always be thrown, so there is the old question again: What differentiates, in practice, an error condition that would raise a checked exception rather than an unchecked one?[5] 4. Protecting from a JVM crash is an application developer's decision. Do we really want to force all to handle checked exceptions just so that the compiler can remind the absent-minded (!) that a "try/catch" may be in order? > > [...] > > 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. How about * removing the "throws" clauses * reverting the addition of the "E" parameter ? > 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. How could that be achieved, short of enclosing all function bodies in a "try/catch" block and rethrowing a checked exception? For what benefit eventually (as asked above)? > 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. AFAICT, unchecked exceptions was the way (a.o. setting an "IOException" as the cause of an "UncheckedIOException"[6] and rethrowing that one). Regards, Gilles [1] https://github.com/apache/commons-pool/pull/143/commits/36ca267abba54dcea11192c61df3ad74a5ac9941 [2] https://issues.apache.org/jira/browse/POOL-269 [3] Is there another library doing that? [4] https://docs.oracle.com/javase/8/docs/api/java/lang/Exception.html#Exception-java.lang.String-java.lang.Throwable- [5] Mimicking the API of the very early days of the JDK. [6] https://docs.oracle.com/javase/8/docs/api/java/io/UncheckedIOException.html --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
