Extend the support for throw expressions

[The-Futurist]

I'm frustrated to see that throw expressions cannot be used neatly in return statements, it would be neat if we could write:

return SomeOperation(args) == 0 ? throw new InvalidOperationException("Something bad happened");

If the result did not equal zero then the return simply returns the result of SomeOperation(args).

Of course use of ? requires one to also specify : but what would that look like in the above code? This is why I ommitted it but if we insisted on retaining : here then we'd need a new keyword result or something (meaning the result that was going to be returned) but adding a new keyword seems overkill hence I suggest making the : optional where we are using a throw expression.

Thoughts?

[HaloFour]

Seems your beef is with conditional operators, not throw expressions.

The problem with this is that the conditional expression is SomeOperation(args) == 0, not SomeOperation(args). As such it wouldn't make any sense for this operator to return SomeOperation(args). For example, IsZero(SomeOperation(args)) is a perfectly legal conditional expression. What would be returned in that case? Or SomeBoolean(args) == false? The concept quickly starts to fall apart with any degree of complexity, but these are normal valid Boolean expressions.

I also believe that allowing the : to be optional would result in ambiguity if you attempt to nested this with normal conditional operators.

[yaakov-h]

What does this significantly offer over:

return SomeOperation(args) is var result && result != 0 ? result : throw new InvalidOperationException(“Something bad happened.”);

?

[jnm2]

@yaakov-h Readability.

[The-Futurist]

@HaloFour -

Seems your beef is with conditional operators, not throw expressions.

Possibly but the overall intent is to be able to include a throw expression when the expression following a return keyword meets certain conditions.

The concept quickly starts to fall apart

Well your examples fall apart because they do not include the suggested ? token (which was just a suggestion anyway). My examples (by virtue of the ?) are not to be interpreted as returning a bool.

[HaloFour]

@Korporal

Possibly but the overall intent is to be able to include a throw expression when the expression following a return keyword meets certain conditions.

Which is fine, throw expressions supports that just fine. The issue here is the lack of syntax which then let's you use throw expressions in a more terse manner.

My examples (by virtue of the ?) are not to be interpreted as returning a bool.

SomeOperation(args) == 0 returns a bool. That is a self-contained expression which must be evaluated in exactly the same manner regardless of whether or not it appears in a conditional operation expression or whether or not it's followed by this binary ? operator that you're suggesting. You can't isolate portions of that bool expression and make that somehow the result of that expression.

[jnm2]

Another option coming soon (sharplab):

return SomeOperation(args) switch
{
    0 => throw new InvalidOperationException("Something bad happened"),
    var result => result
};

[jnm2]

@Korporal You're probably going to be happiest with something like this:

return SomeOperation(args).NullIf(0) ?? throw new InvalidOperationException("Something bad happened");

public static class ValueTypeExtensions
{    
    public static T? NullIf<T>(this T value, T comparison) where T : struct
    {
     	if (EqualityComparer<T>.Default.Equals(value, comparison)) return null;
        return value;
    }
}

[The-Futurist]

@jnm2 - That's not a bad idea, as soon as I coded it it was screaming to be refactored like this:

return SomeOperation(args).ThrowIf(0, new InvalidOperationException("Something bad happened"));

where

    public static class ValueTypeExtensions
    {
        public static T ThrowIf<T>(this T value, T comparison, Exception e) where T : struct
        {
            if (EqualityComparer<T>.Default.Equals(value, comparison)) throw e;
            return value;
        }
    }

[The-Futurist]

@jnm2 - Which upon further pondering becomes:

return SomeOperation(args).ThrowIf(r => r == 0, new InvalidOperationException("Something bad happened"));

where

    public static class ValueTypeExtensions
    {
        public static T ThrowIf<T>(this T value, Func<T,bool> comparison, Exception e) where T : struct
        {
            return comparison(value) ? throw e : value;
        }
    }

[jnm2]

@Korporal I avoid letting library methods throw provided exceptions like that. Mainly because the exception helper filters them as coming from another assembly, but also because it's another thing to document.

[The-Futurist]

@jnm2 - Sure, there are always considerations (but what is "exception helper"?) however the name "ThrowIf" more or less conveys what this does without any need for documentation surely?

[The-Futurist]

@jnm2

In fact this suggest (now that we have gone down this road) a new keyword throwif...

[The-Futurist]

My original example was:

return SomeOperation(args) == 0 ? throw new InvalidOperationException("Error");

With a new keyword throwif we could write:

return SomeOperation(args) throwif (a => a == 0) new InvalidOperationException("Error");

or something, in fact we could retain the existing keyword but have this alternative form:

return SomeOperation(args) throw (a => a == 0) new InvalidOperationException("Error");

Doc:

The expression <expression> throw (<predicate>) <exception> has the value <expression> unless the <predicate> evaluates to true in which case it has the value <exception>

[jnm2]

@Korporal The VS exception helper is this thing (note the assembly name filter):

If you like it, go for it. I'd also recommend lazily creating the exception object if you do that.

[The-Futurist]

If we leverage the new "using"

using static ConsoleApp13.ThrowSupport;

which improves readability, we can have this:

return throwif (SomeOperation(args), r => r == 0, new InvalidOperationException("Bad Result"));

where

    public static class ThrowSupport
    {
        public static T throwif<T>(T Value, Func<T, bool> Predicate, Exception Exception)
        {
            if (Predicate(Value))
                throw Exception;
            return Value;
        }
    }

[paulirwin]

It seems like it might fit better by using proper boolean logic, maybe?

How about this:

return SomeOperation(args) == 0 || throw new InvalidOperationException("Something bad happened");

This approach has a few benefits over the original suggestion: throw expressions remain pretty much the same, just relaxed; ternary syntax doesn't change; no new keywords introduced; and it's readable if you read || as "or". i.e. "return SomeOperation with args equals zero or throw new exception". It also allows you to invert the boolean logic by using && instead:

return IsFailure(args) && throw new InvalidOperationException("Something bad happened");

TBH, I probably wouldn't use this very much, but I wanted to constructively throw an idea out there.

[CyrusNajmabadi]

That actually seems reasonable to me as you could imagine that all throw expressions can have their type inferred by context. So, "throw ..." would just have a boolean type here.