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
