feat: use Result<T> in email settings save path instead of throwing - #142
Merged
Conversation
This was referenced Jul 31, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #141, scoped down from its literal wording after re-reading the actual code:
Fixed — the real convention violation:
IEmailSettingsStore.SaveAsync/MartenEmailSettingsStore.SaveAsyncnow returnResultinstead of throwingInvalidOperationExceptionfor the "no password on first save" case — that's an ordinary validation outcome, not an exceptional condition.EmailSettingsPage.razor'sOnValidSubmitbranches on the result instead ofcatch (Exception ex), and showsresult.Error(our own controlled validation message) instead ofex.Message.Submit_StoreReturnsFailure_ShowsErrorNotificationWithResultMessage) covering the failure-notification path, which had no test coverage before.Deliberately NOT changed, with reasoning:
EmailSettingsPage.razor'sOnSendTest(catch (Exception ex)around the test-email send) — this wraps genuine external SMTP I/O with many real failure modes (network, auth, DNS), not an expected validation condition. Converting it toResult<T>wouldn't fix anything; theex.Messageshown there is also gated behind[Authorize(Roles = "Administrator")], so it's diagnostic info for the person testing their own mail settings, not a leak to an untrusted party.Setup.razor'scatch (Exception ex)(line ~232) — on closer read this already logs properly (Logger.LogError(ex, "Critical error during setup")) and shows a safe, generic message ("Setup could not be completed. Please try again.") — it never leaksex.Message. It's a legitimate top-level safety net around a multi-step admin-bootstrap flow whose individual steps already branch on typed results (IdentityResult,SignInResult). This isn't the "exceptions for flow control" anti-pattern; converting it would add complexity without fixing anything.Verification:
dotnet csharpier format .clean,dotnet build0 errors,dotnet test --filter "FullyQualifiedName!~E2ETests"118/118 passed (117 existing + 1 new),dotnet list package --vulnerable --include-transitiveclean.Closes #141
🤖 Generated with Claude Code