theshoeshiner commented on PR #1156: URL: https://github.com/apache/commons-lang/pull/1156#issuecomment-1902169921
I would say that sequentially invoking the same method on a set of objects is essentially, or exactly, what a listener API does (internally that is), and they rarely use executors, IME. The real difference here is that most providers hard code each listener interaction, despite the fact that it produces redundant code (admittedly reducing redundancy isnt always a worthwhile goal). e.g. there are many methods within `org.apache.commons.io.monitor.FileAlterationObserver` that are identical except for the method that they call on the listeners. I think this EventListenerSupport class is trying to make that less redundant by encapsulating the iteration and reducing the number of internal methods. As expected, the FileAlterationObserver does not attempt to handle listener exceptions, and populates them back out to the provider, so that matches what this class currently does. The more I think about it, the more I wonder why the default behavior should ever be to allow the listener to abort the providers process? I suppose it very much depends on the use case. I think both use cases have their place, and I feel pretty certain if I looked around I could find instances of both. A "fireWithHandler" implementation just allows the provider to exercise the second option, without repetitive try/catch blocks. Same principle as reducing the redundant iteration, just expanded to include exception handling. As far as usefulness, I've used it many times in my current project because as far as I can tell it reliably replaces the pattern, while making it easier to evolve and test the listener API. e.g. because you call the proxy, you dont really have a need for an internal private method to wrap the iteration of the listeners. My _specific_ use case is basically allowing UI components to listen _directly_ to background jobs, and push updates to the user. The UI logic is naturally more difficult to test, and is thus more error prone, but even if it weren't we'd never want UI listeners to cause a critical background process to fail. That entire implementation could probably be replaced by a more loosely coupled publisher API, but for now it's implemented with direct listeners because the updates are instantaneous. The code reduction and my specific use case certainly might not fall under the category of "compelling", so it may not meet the standard to be included here. I'm good if that's the verdict. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
