Closed linkdotnet closed 1 year ago
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
Making DoesNotReturnAttribute
affect definite assignment and reachability was rejected in https://github.com/dotnet/csharplang/issues/2555#issuecomment-495694037 and https://github.com/dotnet/csharplang/issues/3826#issuecomment-681191954. Alternative C# language changes have been discussed in https://github.com/dotnet/csharplang/issues/538 and https://github.com/dotnet/csharplang/issues/739.
Thanks for the swift response @KalleOlaviNiemitalo seems like a duplicate of https://github.com/dotnet/csharplang/issues/739. Thanks. Will close the issue
maybe a new
DoesNotReturnIfNull
would also be helpful
NotNullAttribute on an input parameter already means that, if the function returns, then the compiler can assume that the argument was not null.
True but not in the context of an exception (or whether we can continue the control flow after the method in question).
Problem
In the current setup, there is no way of telling that a method will throw an exception so that the code after will not be executed. A small example:
Even though
AlwaysThrow
will never return and will throw an exception the method would not be compilable without the additional (and useless)throw
at the end (or areturn
statement).Real-world example
I encountered this problem most often in combination with
ExceptionDispatchInfo
:New behavior
We already have
DoesNotReturn
andDoesNotReturnIf
which could be a good beginning. If a method is flagged by this annotation the compiler should understand that the code afterward will never be reached. In its current stateDoesNotReturnIf
only understands a boolean input, maybe a newDoesNotReturnIfNull
would also be helpful.PS: I did neither add this as a proposal nor as a bug as I wasn't sure what category fits best.