Thanks for digging in Mark (more below which will just echo my reply to Phil).
On Thu, Jun 29, 2023 at 5:43 AM Mark Thomas <ma...@apache.org> wrote: > > 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. This is a good point for making the API simpler to use and I think that in the future the implementation should wrap unchecked exceptions as pool exceptions. > > <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. Fair enough, so I am switching my brain to the 3.0 context. > > 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. For some projects, yes of course but in general, I feel you are not quite right here: Software stacks can be so deep these days that a lot of dependencies come in transitively, where binary compatibility is obviously paramount. > > 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. The idea is exactly not that. You would type your factory a domain exception. Typing it as `Exception` would be like typing the domain class to `Object`. > > 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. Agreed, see my other comments. > > 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. We're discussing it now ;-) See my reply to Phil. Gary > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
