Dealing with "using(var disposableRef = methodCall()) {}" where 'methodCall' returns Null

[najak3d]

We are dealing now with Stride3D code, where they have a pattern of this:

try
{
  using (var stream = objectDatabase.OpenStream(objectId))   /// NOTE:  'OpenStream' THROWS if objectId not found
  {
        // process stream
  }
  return true; // success
}
catch {  return false; }

Because they want to have this "using" statement, they are using "exceptions" for normal program flow. It's actually, in many cases OK for the 'objectId' to be missing from the database, in which case we just return 'false' (for failure), and so is not an "error".

==
Questions:

1. Is it still a promoted policy to "avoid using Exceptions as a means for common/expected program flow"? (as it is here)
2. To avoid using exceptions for program flow in the above example, it looks to be "not possible" to have this "using" statement, but instead forces us to simply put the "stream.Dispose()" inside a 'finally' clause (see snippet below).

Part of the goal here is to keep the "using(...)" clause - because it's sexy. But I don't see how we can continue with the "using()" clause in a manner that won't use "exceptions for program flow".

For example, here's the ONLY way I can think for rewriting the above, to avoid Exceptions for Program Flow, but does NOT include the "Using(...)" clause:

try
{
  var stream = objectDatabase.OpenStream(objectId));
  if (stream == null)
    return false;

  // process stream....
  return true; // success
}
catch {   } // handle UNEXPECTED Exceptions that may never happen.
finally { stream?.Dispose(); }

So this 2nd snippet avoids using "exceptions for program flow", but also does not make use of sexy/desired "using(...)" clause.

==
Part of this issue stems from a tug-of-war between these two competing concepts:

1. Wanting to use "Using(...)" clauses, because they are a good practice, AND
2. Avoiding usage of Exceptions for normal program flow.

NOTE: When Exceptions are used for normal program flow, it makes it difficult to manage when you have "Break on Exceptions" turned on, for sake of discovering ACTUAL BUGS fast (rather than continuing to break again and again for normal program flow!).

This is our conundrum -- so am seeking advice if there is a way to satisfy both sides of this tug-of-war...?

[Joe4evr]

1. Is it still a promoted policy to "avoid using Exceptions as a means for common/expected program flow"? (as it is here)

Yes.

2. To avoid using exceptions for program flow in the above example, it looks to be "not possible" to have this "using" statement, but instead forces us to simply put the "stream.Dispose()" inside a 'finally' clause (see snippet below).

You can use the Null Object pattern to deal with situations like this, meaning you return an object where every operation is a no-op. The BCL provides Stream.Null for this purpose, which you could likely use to piggy-back off.

[Richiban]

If you'd like a language feature to support this there's precedence for a "null-aware using" feature in the vein of null-aware await: #35.

Null-aware using would (assumedly) look like this:

using? var disp = GetSomeDisposableThing();

// code

or

using? (var disp = GetSomeDisposableThing())
{
    // code
}

which would differ from regular using by simply add a null check before calling Dispose() in the finally block;

[jnm2]

@Richiban using is already null-aware. It already adds a null check before calling Dispose. (It's been this way from the beginning of C#.)

[Richiban]

Wait... I assumed it didn't because the OP seems to be complaining that it wasn't. Does it turn out, all along, that the feature they want is already there?

[CyrusNajmabadi]

https://github.com/dotnet/csharpstandard/blob/draft-v6/standard/statements.md#1214-the-using-statement

Otherwise, the expansion is

{
    ResourceType resource = «expression»;
    try
    {
        «statement»;
    }
    finally
    {
        IDisposable d = (IDisposable)resource;
        if (d != null)
        {
            d.Dispose();
        }
    }
}

[Richiban]

Yup, just tested and it is, indeed, null-safe. Not really sure what the OP is asking for then; it appears to already work the way they would like.

[jnm2]

@Richiban Possibly. I'm having a hard time understanding the exact ask, but I use this pattern frequently:

using var stream = objectDatabase.OpenStream(objectId);
if (stream is null) return false;

// ...
return true;

[HaloFour]

they are using "exceptions" for normal program flow.

ObjectDatabase has an Exists method, you should be checking that in your program flow rather than relying on an exception being thrown. If you want a single call that checks and returns a sentinel value in the case that the ID doesn't exist, you can write an extension method.

[jnm2]

You can also be "clever" if you want:

using (var stream = objectDatabase.OpenStreamOrNull(objectId)) if (stream != null)
{
    // Use stream
}
else
{
    // handle failure to get a stream
}

[FaustVX]

@jnm2
Personally, I don't really like that one-liner syntax.
At first, I wondered why else was here, then I had to re-read the first line to see the if at the end.

But a mix between yours and @CyrusNajmabadi can be nice :

using (var stream = objectDatabase.OpenStreamOrNull(objectId))
    if (stream != null)
    {
        // process stream
    }
    else
    {
       // handle failure to get a stream
    }

To me, it's way more readable.

[jnm2]

@FaustVX That makes two of us that don't like that syntax 😄

[najak3d]

@CyrusNajmabadi - the solution @HaloFour wrote is what you are suggesting, where it can return null, then do an if/else null check inside the body of the using.

Ideally, this "if" statement would be built into my suggested "TryUsing()" statement, so it would only enter that clause IF the value was non-null, and would go to the Else{} if Null. Same effect as what you guys are suggesting -- but with less code.

Unless a lot of people would benefit from this syntax-efficiency - it's probably not a good suggestion for implementation. But I have no idea how many others would benefit from this "TryUsing()" concept.

What I'm going to go with here is your suggestion, and thus why I marked it as the "answer".

[CyrusNajmabadi]

Ideally, this "if" statement would be built into my suggested "TryUsing()" statement,

Why is that ideal though? The above code is extremely clear to read and is a great composition of orthogonal features. I don't see anything virtuous about combining them here.

What I'm going to go with here is your suggestion,

Sounds good :)