Hi, LUCENENET-598 is reproducible with our current code. There's a failing unit test provided in the issue, and it is fixed by the patch in LUCENE-6001.
I'll write a comment in the issue and leave it open since it is a known bug and have a known fixVersion. (However, our project doesn't have that fixVersion yet, so we cannot properly tag it as such in Jira.) Regarding the permissions; I'm not sure how they are configured. I have permissions to resolve/close issues, but not much more. // Simon Svensson On 2019-01-19 19:12, Laimonas Simutis wrote: > Simon, > > Please see my thoughts below. > > >> LUCENENET-605 is asking to implement ArgumentNullException instead of >> letting null values become NullReferenceException. The current behavior >> matches the Java behavior. >> > > We should close it as won't fix. I was actually going to do that earlier > today but I do not have access to JIRA to close or modify in any way > lucene.net issues. Our goal for 4.8 should be to stay as close to the Java > version as possible and as you said, Lucene has the same behavior, it > throws null exception. That should suffice as a good won't fix reason. > > >> >> LUCENENET-600 is about the number of first-chance exceptions. This >> sounds like another .NET-ification. > > >> About the .NET-ification; is this something we're doing for 4.8? >> > > Same as for LUCENENET-605, it should be left alone and not done for 4.8 > release. I know having gone through fixing hard to track down bugs, if we > start stearing away from the original code base it will be hard to track > down where the problem is. Let's avoid it. I know that there are > performance issues due to exceptions, but again, my vote would be to > address that separately once 4.8 is released. > > >> >> LUCENENET-598 is the same as LUCENE-6001, which was fixed in Lucene >> 4.10. Am I correct in thinking that we do not fix this issue since the >> same problem exists in Lucene's 4.8? >> > > I wonder if somehow we still have that issue in our current 4.8 lucene.net > code base? Were you able to reproduce it based on the example the user > provided? > > >> >> There are three unreleased versions in Jira which I believe we can >> archive; 3.6, 4.0 and 5.0 PCL. Archiving these means that they can no >> longer be selected when new bugs are reported. Do we still have any >> purpose for having these selectable when new issues are filed? >> > > Have no opinion there. > > Laimonas >
