-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FileSystemEnumerator.ContinueOnError() needs overload with context #26710
Comments
Can we expect a such API in the .NET Core 3.0? Why this API like Thank you @JeremyKuhne. |
Possibly. It depends on feedback and available time to allocate internal resources. If someone external wants to take this on it is more likely.
Because we want to be compatible with existing code. We can't call the new method, get true, then not call the old method. We can, however, call the old method, get true, then not call the new method as it would be documented behavior. This would be important if you're deriving from an enumerator that derived from the base only understanding the current behavior. |
Should the |
They should be. Bad habit on my part- I'll update the comment. |
To clarify the top post -- writing up the API proposal is up for grabs. Until that is done and approved, there is no code to write |
Hi, do you have a plan to address this issue in the near future? Thanks. |
@CyberSinh do you want to write the API proposal as suggested above? that is the next step. |
@danmosemsft, thank you for your trust but I think @JeremyKuhne is more qualified than I am to do it. That's why I wanted to know if Microsoft had this feature on its roadmap. Thanks again. |
@CyberSinh that's fine. To answer your question, we don't have a plan to do this in the near future. |
If ContinueOnError() returns false we throw on the error. private bool InternalContinueOnError(Interop.ErrorInfo info, bool ignoreNotFound = false)
=> (ignoreNotFound && IsDirectoryNotFound(info)) || (_options.IgnoreInaccessible && IsAccessError(info))
|| (ContinueOnError(info.RawErrno) && ReportError(...); |
We can: private bool InternalContinueOnError(string currentPath, Interop.ErrorInfo info, bool ignoreNotFound = false)
=> (ignoreNotFound && IsDirectoryNotFound(info)) || (_options.IgnoreInaccessible && IsAccessError(info))
|| ContinueOnError(currentPath, info.RawErrno) || ContinueOnError(info.RawErrno); Since new overload for ContinueOnError() doesn't exist today and default is false we can put it before ContinueOnError(info.RawErrno) overload and existing code will continue work as expected. |
Update: replaced by #1953 (comment) Proposal: namespace System.IO.Enumeration
{
public unsafe abstract partial class FileSystemEnumerator<TResult> : CriticalFinalizerObject, IEnumerator<TResult>
{
[Obsolete("Please use ContinueOnError(string currentPath, int error) instead.")] // New
protected virtual bool ContinueOnError(int error) => false; // Exists
protected virtual bool ContinueOnError(string currentPath, int error) => false; // New
}
public class FileSystemEnumerable<TResult> : IEnumerable<TResult>
{
public delegate bool ContinueOnErrorPredicate(string currentPath, int error); // New
public ContinueOnErrorPredicate? ShouldContinueOnErrorPredicate { get; set; } // New
}
} |
I didn't provide context in the 2.1 release of the APIs as it is somewhat tricky to do without allocating.
Presumably some API like
ContinueOnError(ReadOnlySpan<char> directory, ReadOnlySpan<char> filename, bool directoryOpen)
that gets called ifContinueOnError()
returns false and has a default return value of false.I'm marking this up-for-grabs if anyone wants to tackle it before I find time to.
See #26704.
The text was updated successfully, but these errors were encountered: