Champion: Remove error "Cannot yield a value in the body of a try block with a catch clause"

[gafter]

As recently noted by C# users, the existing restriction that you cannot yield a value in the body of a try block with a catch clause is one that interferes with reasonable code refactoring. The restriction does not make the compiler any easier. Rather it was added to align with the conceptual model that the caller's loop is logically "called" at the point of the yield. But that is not how people think of the construct, and the restriction has little value. We propose to remove it.

[gafter]

This could also affect async iterator methods. We could consider checking VB for alignment.

[hawkerm]

I just hit this message trying to see if I was missing an exception in an iterator I'm trying to write for some database access. What's needed to implement this? Is it just planning/dev cycles or is there something else that needs to be done?

It'd be easier to wrap my whole method in a try/catch as I have a lot of using statements to capture the database handles and contexts. So, it's a bit hard to try and make repeated try/catch around all the database calls and leave the yield statement inside out of it.

[333fred]

What's needed to implement this? Is it just planning/dev cycles or is there something else that needs to be done?

This issue as marked as Any Time and Needs Implementation. It is open for community contribution, but the dev team is unlikely to implement it ourselves.

[MadL1me]

@333fred @jcouv @CyrusNajmabadi So, if its open for community contribution, and I want to contribute, where should I start? This feature is quite big, I think I need some kind of approval to be able to work on this from core roslyn team

[333fred]

@MadL1me feel free to come talk to us on discord.gg/csharp in the Roslyn channel, and we can help guide you.

[koureasstavros]

I just hit this message trying to see if I was missing an exception in an iterator I'm trying to write for some database access. What's needed to implement this? Is it just planning/dev cycles or is there something else that needs to be done?

It'd be easier to wrap my whole method in a try/catch as I have a lot of using statements to capture the database handles and contexts. So, it's a bit hard to try and make repeated try/catch around all the database calls and leave the yield statement inside out of it.

I fully agree, I have same issue, I have a very big function with multiple database calls where at the moment I have a try catch of the whole code to catch any exception may occur. Also I have a case where I am calling same function multiple times with different input parameters, a case where there is the need to break but let the other function call to continue and a case where you can cancel the request and then most of the times database throws an exception. This restriction by implementing try catch to every database statement will make the code not easy to understand. Currently I am using SignalR to sent messages into UI and need to switch to AsyncEnumerable as SignalR brings a headache when you want to scale out your application.

[koureasstavros]

Any updated on this topic?
There are also other connected topics with this one expressing the demand of this feature.

1. Permit yield in catch a̶n̶d̶ ̶f̶i̶n̶a̶l̶l̶y̶ blocks #765
2. yield return isn't allowed in try or catch blocks. docs#42112
3. Cannot yield a value in the body of a try block with a catch clause #6819

[hawkerm]

Yeah, looks like this should be a duplicate of #765. There's a comment there about a proposal: #765 (comment)

That PR here: #8413

[syntactix-nst]

The rise of Large Language Models and AI APIs since 2022 has made this C# restriction significantly more problematic. Modern AI applications heavily rely on streaming responses, and AI services are inherently unreliable (rate limits, server errors, timeouts).

public async IAsyncEnumerable<string> StreamAIResponse(string prompt)
{
    // This won't compile - cannot yield in try block with catch clause
    try
    {
        await foreach (var chunk in _aiClient.StreamAsync(prompt))
        {
            yield return chunk.Text; // Compiler error CS1626
        }
    }
    catch (HttpRequestException ex) // API rate limits, server errors
    {
        // Handle AI service exceptions
    }
    catch (ArgumentException ex) // Bad request format
    {
        // Handle invalid prompts
    }
}

Since many applications now use some kind of connection to an LLM, I expect that many people are affected by this limitation.

[TonyValenti]

I know I am.

[333fred]

@aradalvand this type of interaction is not acceptable. Please refrain from further such comments on other issues.