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

C#: improve WitException.Value type #1042

Open
pavelsavara opened this issue Aug 29, 2024 · 2 comments
Open

C#: improve WitException.Value type #1042

pavelsavara opened this issue Aug 29, 2024 · 2 comments
Labels
gen-c# Related to the C# code generator

Comments

@pavelsavara
Copy link

The pattern where the user code needs to correctly guess type of the ex.Value is fragile.

            catch (WitException e)
            {
                var error = HeaderErrorToString((HeaderError)e.Value);
                throw new HttpRequestException($"Header validation error: {error}");
            }

The cast here could throw invalid cast exception or could give misleading information.

Should we generate WitHeaderException and make the conversion on behalf of the user ?

cc @jsturtevant @dicej

@jsturtevant jsturtevant added the gen-c# Related to the C# code generator label Nov 6, 2024
@kaivol
Copy link

kaivol commented Nov 19, 2024

Alternatively, I would like to suggest not using exceptions for WIT results and instead directly returning the Result<Ok, Err>.
Using features like [MemberNotNullWhen] this could also be very ergonomic in my opinion.
It would also prevent users from accidentally throwing errors that the current function can't actually return.

@dicej
Copy link
Collaborator

dicej commented Nov 19, 2024

Alternatively, I would like to suggest not using exceptions for WIT results and instead directly returning the Result<Ok, Err>. Using features like [MemberNotNullWhen] this could also be very ergonomic in my opinion. It would also prevent users from accidentally throwing errors that the current function can't actually return.

That's how it used to work prior to #968. I think both approaches have merit, and I'd suggest providing an option to allow the user to choose at binding generation time, with some reasonable default if not otherwise specified.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gen-c# Related to the C# code generator
Projects
Status: No status
Development

No branches or pull requests

4 participants