runtime: File open should have non-throwing alternatives

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)”

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):

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) { 
  ...
}

…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?

@migueldeicaza

While I like discriminated unions, the problem I see with Result<T, E> is that we already have the equivalent error feature.

You know, exceptions.

Essentially we’d be propagating a second, “softer” form of exceptions, ones declared as part of the API. Given we already have exceptions, I think I’d prefer going the Midori route: methods either explicitly throw a specific set of exceptions that can be recovered from, or none. Things that can’t be recovered from - which is usually from programmer error - cause abandonment (essentially, exit the running task/process/application).

The language is already starting to move in the direction where such a thing might be viable; we’re getting non/nullable reference types, meaning NullReferenceException (which is - usually - caused by programmer error, should be fixed, and would cause abandonment under this model) should go away. You can write code to take Span<T>s or Memory<T>s for slices, which help avoid index-out-of-bounds… as would (hopefully) the upcoming Range feature.

So, what’s the progress on this after 3 years?

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.

One possible consideration is to wait until C# gets discriminated unions, and then change our APIs to support the Result<T,E> idiom as seen in languages like Rust, F# and Swift:

• F# https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/results
• Rust: https://doc.rust-lang.org/std/result/
• Swift: https://developer.apple.com/documentation/swift/result

SocketError.Success and WebSocketError.Success is existing prior art for having success code in error code enums.

I love the proposal, but would:

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

Wouldn’t that defeat the purpose of the Try pattern? I think Try only works when there’s one response to error.

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.

Per discussion in dotnet/runtime#926 this is not possible to do in a reasonable cross platform way, for many common cases.

@jaredpar Do you think you’d consider introducing an error enum for this API instead of just returning bool so that it can be used for scenarios like the one outlined in dotnet/runtime#926?

Scenario: I want to create and write some default data into a file unless it already exists.

where it’s needed to treat very specific failures specially and completely ignore them because they are expected (as opposed to other errors).

I like the idea at face value with the given history of the Try pattern. But, thinking through some scenarios, I’m no longer sure.

I think part of the problem is the ambiguity of File.Open. This ambiguity leads you to the need for something like TryOpen; but also telescopes the ambiguity, in my mind. I’d first try to address the ambiguity because there’s multiple reasons why you’d call File.Open and thus multiple things you’d want to do when unsuccessful. This leads to questions about error codes, etc. Off the top of my head, I’d consider deprecating Open and focus on OpenRead, OpenWrite, and OpenText. But, with Try variants of those, their usage becomes more awkward in light of IDisposable.

It can be made to work with using by switching what goes in the out parameter:

IOStatus status;
using (var stream = File.TryOpen("foo.txt", out status))
{
    // ...
}

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
     ...
}

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

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?.

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
    }
}

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)) { }
}