Could possibly call to method annotated with [DoesNotReturn] spare you writing return statement?

[FLAMESpl]

Following code:

    public static async Task<T> InvokeWithTargetInvocationExceptionUnpacking<T>(
        this MethodInfo methodInfo, 
        object? instance, 
        object[] parameters)
    {
        var task = (Task<T>)(methodInfo.Invoke(instance, parameters) 
            ?? throw new InvalidOperationException("Method returned null object"));

        try
        {
            return await task;
        }
        catch (TargetInvocationException exception) when (exception.InnerException != null)
        {
            ExceptionDispatchInfo.Capture(exception.InnerException).Throw();
        }
    }

produces compilation error CS0161: not all code paths return a value.

ExceptionDispatchInfo.Throw() method is annotated with [DoesNotReturn] so it is guaranteed to throw, why am I forced to write return statement after try...catch expression or inside catch block itself.

Putting [DoesNotReturn] attribute on method that will return is forbidden with compilation error.

[CyrusNajmabadi]

Because DoesNotReturn isn't actually a contract. It can trivially be violated. However, the compiler 'reachability analysis' is precise and depends only on things it can prove. As it cannot prove that DoesNotReturn is true, it must error.

[TahirAhmadov]

The language could add a keyword and make it a feature that way, right? I'm not saying it's high priority, but want to make sure I understand this situation correctly.

[333fred]

That's #538.

[erik-kallen]

The compiler could insert throw new InvalidOperationException("Unreachable code reached") immediately after the call to the [DoesNotReturn] method.

[FaustVX]

@erik-kallen
FYI, instead of writing new InvalidOperationException("Unreachable code reached"), there is a new UnreachableException() since .NET7

[RikkiGibson]

Is there some specific reason the API is designed to "wrap" the throw statement, when it is intended to be called within catch blocks?

The main reason I'm aware of to wrap throw statements in this way is to make it so your method can still be inlined. But that's already not going to happen in a method with a try/catch, I think.