考虑以下方法签名：
public static bool TryGetPolls(out List<Poll> polls, out string errorMessage)
该方法执行以下操作：
这是一个好的编程风格吗？
更新：
假设我使用以下方法签名：
public static List<Poll> GetPolls()
在那个方法中，它不会捕获任何异常（所以我依赖调用者来捕获异常）。如何处理并关闭在该方法范围内的所有对象？一旦抛出异常，关闭和处理方法中的对象的代码就无法访问。
该方法试图执行三个不同的操作：
从设计的角度来看，这相当混乱。
更好的方法是简单地声明：
public static List<Poll> GetPolls()
如果有任何错误发生，那么就让这个方法抛出一个Exception异常。
我相信
public static bool TryGetPolls(out List<Poll> polls)
更为适当的方式是使用 TryGet 方法。如果方法是一个 TryGet，那么我的初步假设就是存在失败的可能性，并且责任在于调用者确定接下来该做什么。如果调用者没有处理错误，或者想要错误信息，我会期望他们调用相应的 Get 方法。
这绝对不是编写C#的惯用方式，这也意味着这可能不是一个好的风格。
如果您有一个TryGetPolls方法，那么它意味着如果操作成功，您希望得到结果，如果不成功，则您不关心失败原因。
如果您只有一个GetPolls方法，那么它意味着您总是希望得到结果，如果不成功，则希望以Exception的形式知道失败原因。
将两者混合在一起介于其中间，这对大多数人来说都很奇怪。因此，我建议要么不返回错误消息，要么在失败时引发一个Exception，但不要使用这种奇怪的混合方法。
因此，您的方法签名应该是以下之一：
IList<Poll> GetPolls();
bool TryGetPolls(out IList<Poll> polls);
请注意，我返回的是一个 IList<Poll> 而不是一个 List<Poll>，因为编程应该按照抽象而不是实现进行。
public static bool TryGetPolls( out List<Poll> polls );
public static List<Poll> GetPolls();
这样用户就可以做出适当的行动，GetPolls 可以在 TryGetPolls 的基础上实现。我假设你的静态性在上下文中是有意义的。
考虑返回：
对我来说，多个输出参数是一种代码异味。该方法应该只做一件事。
考虑使用以下方式引发和处理错误消息：
throw new Exception("Something bad happened");
//OR
throw new SomethingBadHappenedException();
public static List<Poll> GetPolls();
这取决于错误信息是什么。例如，如果由于数据库连接不可用等原因导致无法继续处理，则应像其他人提到的那样抛出异常。
但是，也可能只是想返回有关尝试的“元”信息，在这种情况下，您只需要一种方法来从单个方法调用返回多个信息。在这种情况下，建议创建一个PollResponse类，其中包含两个属性：List < Poll > Polls和string ErrorMessage。然后让您的方法返回一个PollResponse对象：
class PollResponse
{
public List<Poll> Polls { get; }
public string MetaInformation { get; }
}
编程指南建议尽量避免使用ref和out参数，除非它们是绝对必要的，因为它们会使 API 更难使用（不能再链接方法，开发者必须在调用方法之前声明所有变量）。
另外，返回错误代码或消息不是最佳实践，最佳实践是使用异常和异常处理进行错误报告，否则错误很容易被忽略，并且传递错误信息需要更多的工作，同时丢失有价值的信息，如堆栈跟踪或内部异常。
一种更好的声明方法是这样的。
public static List<Poll> GetPolls() ...
并且在错误报告方面使用异常处理
try
{
var pols = GetPols();
...
} catch (DbException ex) {
... // handle exception providing info to the user or logging it.
}
不完全是这样的 - 我可以看到这个方法存在许多问题。
首先，该方法听起来像是通常期望它成功的方法；错误（无法连接到数据库、无法访问polls表等）很少见。在这种情况下，使用异常报告错误要合理得多。 Try...模式用于通常期望调用“失败”的情况 - 例如，在将字符串解析为整数时，字符串很可能是用户输入的，可能无效，因此需要有一种快速处理此类情况的方法 - 因此使用TryParse。但这里并非如此。
其次，您将错误报告为指示错误存在或不存在的bool值和一个字符串消息。那么调用者如何区分各种错误呢？他肯定不能匹配错误消息文本 - 那是一个实现细节，可能会更改，并且可以本地化。而且，“无法连接到数据库”之类的内容可能与“已连接到数据库，但显示“访问被拒绝””之间存在天壤之别。您的API没有提供良好的区分这些错误的方法。
我会这样重新表述。
public static List<Poll> GetPolls()
{
...
}
如果无法检索到投票，则应该抛出异常（errorMessage），这样可以进行方法链接，比处理输出参数更方便。
如果运行FxCop，您需要将List更改为IList以使其正常工作。