NightOwl888 commented on PR #1148: URL: https://github.com/apache/lucenenet/pull/1148#issuecomment-2733552640
Thanks for looking into this. I knew there was something in Lucene.Net.Store that was not using `Dispose()` correctly. But, I agree with your points about not changing this. Sometimes it makes sense to use (abuse?) `Dispose()` just so the compiler will give us a free way to put it into a `using` block, even if the implementation is meant to be reused. Also, since you mentioned that this eventually *will* be non-reusable in the future, it would probably be less intrusive for users to have to change to `Close()` only to change again to `Dispose()` later. In addition, I agree that creating a custom reusable `Lock` with disposable components is probably an extreme edge case. `FallbackNativeFSLock` also only loads when the HResult for the lock sharing exception cannot be determined on the current OS, and AFAIK, that never happens in practice. There is a non-zero chance that it *could* happen, and `FallbackNativeFSLock` is there to fill the gap. However, I suspect we can completely eliminate that implementation and approach if `NativeFSLockFactory` were converted to actually use native method calls instead of relying on exceptions (which are raw `IOExceptions`, making them ambiguous except for the HResult value). -- 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]
