uschindler commented on pull request #643:
URL: https://github.com/apache/lucene/pull/643#issuecomment-1030601129
In general I like the idea here, but I would do one change: You already
defined a new functional interface, but the public methods taking Supplyier. I
am against uselessly wrapping exceptions just because the stupid old Java
concept of "checked" exceptions.
My proposal would be:
- Define a `@FunctionalInterface public interface ResourceSupplier<T> { T
get() throws IOException; }` in Lucene's core module next to IOUtils (or maybe
inside IOUtils). I say this, because we may use the supplier pattern now more
often and when Nori is also changed, we would need the interface again.
- The constructors take `ResourceSupplier<InputStream>`
If you still want to go the wrapping, you may also have a look at
https://twitter.com/thetaph1/status/1487397163718135812
This shows that you can trick out Java compiler and convert functional
interfaces (by casting them using generics) to allow them to throw checked
exceptions. I had a similar problem like this in some large codebase using
`SQLException` and many `Function`, `Supplier`, `Consumer`. The trick was to
just make the exceptions invisible to the stupid javac compiler :-) - it is
perfectly legal code and won't break as it follows the laguage spec. It is just
casting Exceptions away.
--
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: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
