C#中是否应将Try...()风格函数改为多返回值形式？

Great question—this is one of those ongoing debates in the .NET community that balances tradition, readability, and modern language features. Let’s break down the pros of each approach and help you make a call based on your context:

Traditional bool TrySomething(..., out T result) Pros #

• Universal familiarity: Every .NET developer knows this pattern (think int.TryParse). If you’re working on an established codebase or with a team that prefers legacy-style code, sticking with this avoids unnecessary onboarding friction.
• Conditional clarity: The syntax if (TryGetUser(userId, out var user)) reads almost like plain English—you immediately understand "if we successfully get the user, use it".
• Multi-out flexibility: For methods that need to return multiple values alongside the success flag (e.g., bool TryValidateInput(string input, out int parsedValue, out string errorMessage)), the out parameter pattern keeps each return value explicitly named and easy to handle in-line.

Tuple-Based (bool Success, T Result) TrySomething(...) Pros #

• Modern C# alignment: Tuples fit seamlessly with other modern features like deconstruction, pattern matching, and async/await (you can’t use out parameters in async methods—huge win here).
• Flexible value handling: You can store the entire result directly (var getUserResult = TryGetUser(userId)), pass it to other methods, or deconstruct it when you need it:

  var (success, user) = TryGetUser(userId);
  if (success) { /* use user */ }
  

• Consistent multi-return style: If your codebase already uses tuples for other multi-value returns, this keeps your method signatures uniform instead of mixing two different patterns.

Practical Recommendations #

• Stick with traditional if: You’re maintaining a legacy codebase, your team is less familiar with modern C# features, or you need multiple out parameters.
• Go tuple-based if: You’re starting a new project, rely heavily on async methods, or want to embrace modern C# idioms for cleaner, more flexible code.
• Prioritize team consistency: Whichever you choose, make sure the team agrees on a standard to avoid mixed patterns in the same codebase—consistency beats "perfect" every time.

At the end of the day, there’s no one-size-fits-all answer. It’s all about what works best for your project’s needs and your team’s comfort level.

内容的提问来源于stack exchange，提问作者jamesmus