Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code annotation for Exceptions #79647

Closed
linkdotnet opened this issue Dec 14, 2022 · 5 comments
Closed

Code annotation for Exceptions #79647

linkdotnet opened this issue Dec 14, 2022 · 5 comments

Comments

@linkdotnet
Copy link

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:

bool Throw()
{
    try
    {
        ActionWhichMightThrow();
        return true;
    }
    catch (Exception)
    {
        AlwaysThrow();

        // Never reached, but we have to add this
        throw;
    }
}

[DoesNotReturn]
void AlwaysThrow() => throw new Exception();

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 a return statement).

Real-world example

I encountered this problem most often in combination with ExceptionDispatchInfo:

try
{
    return waiter.WaitTask.GetAwaiter().GetResult();
}
catch (AggregateException e) when (e.InnerExceptions.Count == 1)
{
    ExceptionDispatchInfo.Capture(e.InnerExceptions[0]).Throw();

    // Unreachable code
    throw;
}

New behavior

We already have DoesNotReturn and DoesNotReturnIf 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 state DoesNotReturnIf only understands a boolean input, maybe a new DoesNotReturnIfNull 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.

@dotnet-issue-labeler
Copy link

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.

@ghost ghost added the untriaged New issue has not been triaged by the area owner label Dec 14, 2022
@KalleOlaviNiemitalo
Copy link

Making DoesNotReturnAttribute affect definite assignment and reachability was rejected in dotnet/csharplang#2555 (comment) and dotnet/csharplang#3826 (comment). Alternative C# language changes have been discussed in dotnet/csharplang#538 and dotnet/csharplang#739.

@linkdotnet
Copy link
Author

Thanks for the swift response @KalleOlaviNiemitalo
seems like a duplicate of dotnet/csharplang#739. Thanks. Will close the issue

@ghost ghost removed the untriaged New issue has not been triaged by the area owner label Dec 14, 2022
@KalleOlaviNiemitalo
Copy link

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.

@linkdotnet
Copy link
Author

True but not in the context of an exception (or whether we can continue the control flow after the method in question).

@ghost ghost locked as resolved and limited conversation to collaborators Jan 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants