Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

[API Proposal]: try-catch with fallback #8686

Closed
PieterjanDeClippel opened this issue Nov 26, 2024 · 2 comments
Closed

[API Proposal]: try-catch with fallback #8686

PieterjanDeClippel opened this issue Nov 26, 2024 · 2 comments

Comments

@PieterjanDeClippel
Copy link

PieterjanDeClippel commented Nov 26, 2024

Background and motivation

Provide a shorter notation for commands with fail-cases

Prevents developers from writing the following

namespace System.Collections.Generic;

void Example() {
    try {
        Method1();
    } catch(Exception ex1) {
        try {
            Method2();
        } catch(Exception ex2) {
            try {
                Method3();
            } catch(Exception ex3) {
                Console.WriteLine("Couldn't do it");
            }
        }
    }
}

API Proposal

namespace System.Collections.Generic;

void Example() {
    try {
        Method1();
    } fallback(Exception ex1) {
        Method2();
    } fallback(Exception ex2) {
        Method3();
    } catch(Exception ex3) {
        Console.WriteLine("Couldn't do it");
    }
}

API Usage

namespace System.Collections.Generic;

void Example() {
    try {
        Method1();
    } fallback(Exception ex1) {
        Method2();
    } fallback(Exception ex2) {
        Method3();
    } catch(Exception ex3) {
        Console.WriteLine("Couldn't do it");
    }
}

Alternative Designs

No response

Risks

Variables from a former scope are not available in subsequent fallback blocks

@huoyaoyuan
Copy link
Member

This is a C# language proposal, not runtime API proposal. It should go to https://github.com/dotnet/csharplang/discussions .

This is very unlikely to be considered because it's not a common or encouraged pattern. Related to #1015 and #4676 .

@Zintom
Copy link

Zintom commented Nov 26, 2024

I feel like this could be implemented at an application level rather than updating the runtime/language.

There are libraries that already do this.

@jeffschwMSFT jeffschwMSFT transferred this issue from dotnet/runtime Nov 26, 2024
@jnm2 jnm2 converted this issue into discussion #8687 Nov 26, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

3 participants