File open should have non-throwing alternatives

[jaredpar]

Opening a file today in. NET today requires developers to introduce exception handling into their code. That is often unwanted and adds unnecessary complexity to otherwise straight forward code. .NET should offer non-throwing alternatives to facilitate these cases.

Rationale and Usage

File operations in .NET today require developers to introduce exception handling for even the simplest of operations. This is due to a combination of the operations being inherently unpredictable in nature and the BCL only provides exceptions as a way to indicate failure.

This is problematic because it forces exception handling into every .NET app which use the file system. In many cases developers would prefer to use simple if checks as it fits into the flow of their code. This is particularly true of lower level code which tends to be written with local control flow vs. exceptions. Using .NET though there is no way to avoid exceptions when dealing with the file system.

Additionally this is particularly annoying when debugging code in Visual Studio. Even when code has proper exception handling VS will still break File.Open calls when first chance exceptions are enabled (quite common). Disabling notifications for these exceptions is often not an option because in addition to hiding benign case it could hide the real error that you're trying to debug.

Many developers attempt to work around this by using the following anti-pattern:

static bool TryOpen(string filePath, out FileStream fileStream) {
    if (!File.Exists(filePath)) {
        fileStream = null;
        return false;
        
    }
    fileStream = File.Open(filePath);
    return true;
}

This code reads great but is quite broken in at least the following ways:

1. The developer mistakenly assumes that File.Exists is a side effect free operation. This is not always the case. Example is when filePath points to a named pipe. Calling Exists for a named pipe which is waiting for a connection will actually complete the connection under the hood (and then immediately break the pipe).
2. The File.Open call can still throw exceptions hence even with the File.Exists predicate. The file could be deleted between the call, it could be open as part of an NTFS transactional operation, permissions could change, etc ... Hence correct code must still use exception handling here.

A more correct work around looks like the following. Even this sample I'm sure is subtle to cases that would have an observable difference from just calling File.Open):

static bool TryOpen(string filePath, out FileStream fileStream) {
    if (!filePath.StartsWith(@"\\.\pipe", StringComparison.OrdinalIgnoreCase) && !File.Exists(filePath)) {
        fileStream = null;
        return false;
    }

    try { 
        fileStream = File.Open(filePath);
        return true;
    }
    catch (Exception) { 
        fileStream = null;
        return false;
    }
}

To support these scenarios .NET should offer a set of file system helpers that use return values to indicate failure via the Try pattern: File.TryOpen.

Proposed API

public static class File {
    public static bool TryOpen(
        string path, 
        FileMode mode, 
        FileAccess access, 
        FileShare share, 
        out FileStream fileStream);

    public static bool TryOpen(
        string path, 
        FileMode mode, 
        out FileStream fileStream);

    public static bool TryOpen(
        string path, 
        FileMode mode, 
        FileAccess access,
        out FileStream fileStream);

Details

• Considered TryOpenExisting instead of TryOpen as there is prior art here in
  Mutex.TryOpenExisting. That seems like a good fit for Mutex as it had an OpenExisting method. Not a good fit for File which has Open
  and a series of other modes via FileMode that don't like up with the terminology Existing.
• Considered expanding this to other types like Directory. Similar rationale exists for that but the File examples are much more predominant. Can expand based on feedback.
• Any pattern which involves File.Exists is inherently broken. When many developers are using it for common patterns it generally indicates there is a more correct API that has not been provided.

[tannergooding]

CC. @JeremyKuhne, @pjanotti

[roy-t]

I think this is a good idea. But what about combining this with using?

Since a stream is disposable, I think a new pattern for opening files should work well with using statements. Do you have any ideas for that? Something like the below won't compile. (Using variables are immutable so they cannot be passed by ref).

(Or am I overlooking something?)

using (Stream stream = null)
{
  if (File.TryOpen("foo.bar", out stream)) { }
}

[benaadams]

Do you have any ideas for that? Something like the below won't compile.

This should work

if (File.TryOpen("foo.bar", out Stream stream)) 
{ 
    using (stream)
    {
        // do something with Stream
    }
}

[migueldeicaza]

I love the proposal, but would:

• tune to return an error code, so in a single go, i can handle different error conditions.
• extend this to other APIs, there are additional Open methods
• Consider a tuple return “(Status status, FileStream output)”

[Clockwork-Muse]

...how does this interact with the fact that Read/Write (and all their variants) can still throw I/O errors? A handle having been valid at one point won't guarantee it stays that way, right?

[benaadams]

Consider a tuple return “(Status status, FileStream output)”

Are you feeling TryOpenAsync with that pattern?

(Status status, FileStream output) = await File.TryOpenAsync("foo.bar");

Cloudflare: How we scaled nginx and saved the world 54 years every day

So I modified NGINX to do most of open() inside the thread pool as well so it won't block the event loop. And the result (both non-blocking open and non-blocking read):

[ltrzesniewski]

Why not just return null on failure, to make it easy to combine with using?

using (var stream = File.TryOpen("foo.txt"))
{
    // ...
}

I know it doesn't fit well with the bool TryXxx(..., out var result) convention, but I think the ease of use with using outweighs this.

When nullable types make it into the language, turn that into a FileStream?.

[jaredpar]

Why not just return null on failure, to make it easy to combine with using?

Once you eliminate exceptions there is really no way to have it work as easily with using. There is always an if check that has to happen. Consider both cases a) return null and b) return bool).

// Option A: return null
using (var stream = File.TryOpen("bah.txt")) {
  // Still have to account for stream being null before I can call Write, Close, etc ... 
  if (stream == null) { 
    return;
  }
}

// Option B: return bool
if (!File.TryOpen("blah.txt", out var stream)) { 
  return;
}
using (stream) { 
  ...
}

[ltrzesniewski]

That's true, although I'm worried the using will be easier to forget if you return bool. Maybe that's just me though.

[brucificus]

I realize it's probably a hair more "functional" than C# historically leans, but what about church encoding?

Given something like:

interface IFileOpenResult : IDisposable {
    T Match(Func<Stream, T> onSuccess, Func<T> onAccessDenied, Func<T> onSomeOtherFailureReason …);
}
public static class File {
    public static IFileOpenResult TryOpen(string path, …) { … }
}

Consuming code could be written in the form of:

using(var fileOpenResult = File.TryOpen(…)) {
    var dataOrFailureReason = fileOpenResult.Match(
        (s) =>  /* read & return data from stream */ ,
        onAccessDenied: () => null,
        onSomeOtherFailureReason: () => throw new Exception("I really wasn't expecting this!"));
}

I've personally used this pattern often in line-of-business apps in order to avoid using either exceptions or switch statements for control flow.

Some might find, though, that this brings a burden for consumers to have a suitable common return type from the matcher parameters. Third party libraries can help such consumers, but standard library support for things like Some, OneOf, etc. could mitigate some of this.

Of course, then we get into maybe wanting better language (C#, VB) support for some functional programming idioms (monoid comprehenions, Void as a first-class citizen, "closed" type hierarchies for better pattern matching of discriminated unions, etc.) But I digress.

[knocte]

tune to return an error code, so in a single go, i can handle different error conditions.

If the developer wants to handle error conditions, she should use the normal non-Try API, right? This is the way error conditions are propagated in .NET: exceptions. Otherwise, I don't get it.

[MarcoRossignoli]

tune to return an error code, so in a single go, i can handle different error conditions.

@migueldeicaza i like the idea of Status(for clever transient strategies) but i would put as non mandatory overload, something like:

public static class File {
    public static bool TryOpen(
        string path, 
        FileMode mode, 
        FileAccess access, 
        FileShare share, 
        out FileStream fileStream,
        out Status status);
...

public enum Status
{
     SUCCESS,
     FILE_NOT_FOUND,
     ERROR_SHARING_VIOLATION, <- or generic name
     ...
}

[kumpera]

Most code wants to stop on first error but continue unobstructed, so I think we should borrow from languages like Rust with Option/Result.

[abatishchev]

What about TryReadAllLines and TryReadAllText which return string[] and string respectively and don't have complication with using? Maybe start with them and add/implement TryOpen later? Once design is more matured, or C# will have better support for options, etc.

[benaadams]

What about TryReadAllLines and TryReadAllText which...

Doesn't help when probing the binary file to open from a set of possible paths