why can't we use re-throw with the ternary operator?

[jinujoseph]

From @a-a-k on August 16, 2018 16:48

In C#7 we can write this:

var a = 1 < 2 ? "true" : throw new Exception();
why can't we to do rethrowing? For example:

try
{
    var er = 1/0;
}
catch (Exception ex)
{
    var a = ex.InnerException == null ? ex.Message : throw;
}  

As far as my understanding of standart using try-catch-throw, there is some «context» (contains throwed exception) in the try-catch block passed into throw as non-obviously argument. Isn't it?

The same question with the null-coalescing operator - ??.

Copied from original issue: dotnet/roslyn#29343

[jinujoseph]

From @CyrusNajmabadi on August 16, 2018 17:59

This post is asking about a potential change to the language. Requests for language changes should be filed at: dotnet/csharplang.

Thanks!

[a-a-k]

@jinujoseph okay, but could you explain me such current behaviour?

[CyrusNajmabadi]

There's nothing really to explain. When we added throw-expressions, we simply spec'ed it to be only of the form throw <expr>. So throw on its own in expression contexts simply is not allowed.

That said, i see nothing wrong with supporting this. It just likely wouldn't be a high priority.

[jnm2]

I personally don't mind us keeping the current friction against throw;. throw; is always the worst alternative. Try to use exception filter if humanly possible; otherwise the original stack trace is lost on .NET Framework and .NET Core 1.x. otherwise the stack is unwound which makes debugging harder.

try
{
    var er = 1/0;
}
catch (Exception ex) when (ex.InnerException != null)
{
    var a = ex.Message;
}

(This is also off-topic, but you shouldn't write a catch-all except as a top-level application error handler.)

[gafter]

Part of the reason for simplifying the specification for throw expressions to forbid "rethrow" is that it would have made the specification more complex - for example, we'd have to forbid rethrow in exception filters. That would have been possible but the benefit of doing so was perceived to be not worth the effort.

It is still possible to extend the language feature further to support this. If you really care about it, make a feature request. So far nobody has cared enough.

I hope this answers your question.

[GSPP]

@jnm2 throw; preserves the stack traces in contrast to throw ex;. I agree, though, that filters are a good alternative.

[jnm2]

@GSPP I appreciate that, thanks. I think I had known that at one point.

[jnm2]

How long should this issue stay open?

[mwpowellhtx]

@jnm2 So, from the Gitter trace. Conversation somewhat hijacked over petty stuff. This may work for you:

using System;

namespace CSharpLangGitter
{
    public class Program
    {
        static bool CheckReturnAlternatives()
        {
            bool DefaultAlternative(Exception ex)
            {
                // Assuming throwing ex here really does reset the stack trace.
                throw new Exception($"Wrapper exception preserves {nameof(ex)} stack trace", ex);
            }

            bool? value = null;
            try
            {
                throw new Exception();
            }
            catch (Exception ex)
            {
                return value ?? DefaultAlternative(ex);
            }
        }

        public static void Main()
        {
            CheckReturnAlternatives();
        }
    }
}

Short of a ternary language feature...

[mwpowellhtx]

@jnm2 It seems you have to fake out the operator, but from there you can throw or wrap the caught exception, depending on what really happens with the stack trace.

[CyrusNajmabadi]

@mwpowellhtx As per the gitter conversation, your solution doesn't actually address the problem. You are not throwing the original exception anymore.

[mwpowellhtx]

@CyrusNajmabadi I do not need to throw the original, I've preserved it as the InnerException. As long as he can still get to the stack trace somehow problem solved. Out here.

[CyrusNajmabadi]

@CyrusNajmabadi I do not need to throw the original, I've preserved it as the InnerException. As long as he can still get to the stack trace somehow problem solved. Out here.

Then just write:

throw new Exception($"Wrapper exception preserves {nameof(ex)} stack trace", ex);

There's no need for the inner local function.

[YairHalberstadt]

@mwpowellhtx
What if the original exception was of a specific type, which you try to catch later on, but can't because you've wrapped it in an exception?

[mwpowellhtx]

@CyrusNajmabadi Context is king. He wants ternary support for it. Short of that, I've achieved that.

@jnm2 Prima Facie, more context would be helpful though, a working example, what you're really driving at, etc. I think we're second guessing at that, to be honest.

[CyrusNajmabadi]

@CyrusNajmabadi He wants ternary support for it. Short of that, I've achieved that.

THere is already '??' support if you are willing to not use throw. You can already do var a = ex.InnerException == null ? ex.Message : throw ex;

Literally the entire purpose of this issue is about wanting the behavior of throw; except with ??.

Context is king.

Indeed. I would recommend you reread this issue (and the gitter discussion). You seem to have missed the important context entirely an derailed things with a solution that doesn't actually address the core point of the discussion.

[mwpowellhtx]

Did not know that, thank you. ```C# var a = ex.InnerException == null ? ex.Message : throw ex; ``` @CyrusNajmabadi But for the reset of the stack trace. ;-)

[CyrusNajmabadi]

@mwpowellhtx pinged you on gitter.im about this.