uschindler edited a comment on pull request #643: URL: https://github.com/apache/lucene/pull/643#issuecomment-1030835988
> > The try...catch posted above is.... bad code anyways. Better use finally blocks to ensure something is executed for sure. > > I know it can be written differently, but that's not the point, Uwe - I just showed an example of what can be lurking in the code you can't/ don't control (including the streams implementation). Like I said, I got burnt on this once and I tried not to abuse the type system's loopholes ever since. That's OK. I just wanted to say: When working with MethopdHandles the general rule, also internally followed by the JDK code is to rethrow the original exception. If you have a method Handle you are the only one who knows from the inspection of the type system which Exceptions it really throws. If you would me to enforce not use rethrow or type casting here, I'd like you to open many bug reports in Elasticsearch Painless and the JDK source code's implementations of StringConcatFactory and LambdaMetaFactory. Both of those just rethrow exceptions everywhere. When working with MethodHandles you have to accept that you have left the type system and have to implement the type system on your own -- sorry. There it does not help if you wrap with runtime exceptions, because then the caller no longer gets exceptions that were expected. The problem I see with RuntimeExceptions and wrapping them for nonsense is that the caller of your method doing this no longer sees original exceptions. So you have to find the balance. And my balance clearly says: Throw exactly what you get inside your complex method handles logic. It is only important to REDECLARE the Exceptions excpected in the public API you expose to outside (that's what JDK and Painess does). Internally it ignores type system (also for performance). -- 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
