Question

当我在实用程序模块中编写一个函数以便再次使用时，我倾向于在函数顶部留下大量注释，并且如果函数使用不当，我会在调试器中抛出一些简单的输入检查，没有简单地使用throw命令。

处理此类情况的最佳方法是什么？在C＃中最容易使用哪些功能？

在十年前的CS课程中，我们只需在C ++中使用一个assert（...）命令，如果错误地使用了某些内容，程序就会爆炸。

现在我正在使用C＃我使用了两种方法，抛出一个MessageBox.Show（“...”）来阐明函数过早返回的原因或者Console.WriteLine（“...”）只在调试控制台中解释它。

我目前正倾向于编写一个自定义的ErrorMessage函数来检查构建类型，并可能在显示任何内容之前调整#define master切换，如果我处于beta环境，可能会保存到.log文件。

在这样的实用程序模块中使用的最佳方法是什么？

Answer 1

如果使用无效参数调用该方法，则它应抛出ArgumentException或从中派生的异常。如果正在调用当前由于对象状态而无法调用的方法，那么它应抛出InvalidOperationException。

其他人打电话给你的图书馆不会感谢你以非标准或非显而易见的方式做事。如显示消息框。特别是如果他们从网站或无法显示UI的Windows服务调用您的库。输出到调试窗口很可能不会错过。

Answer 2

抛出异常。这是表明错误的最明确方式，而且比控制台消息甚至消息框更难被忽略。

特别是，这意味着代码路径不会继续，假设一切都很好。即使用户（无论是否处于测试阶段）注意到消息框，他们也不会乐意发现，只要他们点击“确定”，应用程序就会继续并仅仅因为实用程序而清除数据方法没有正确使用。

Answer 3

我同意Jon的回答，但您也有Debug.Assert作为工具包的一部分。有时，如果您想要警告开发人员某些内容，但希望它能够在生产代码中滑过，那么这可以更好地为您服务。

Answer 4

我喜欢pipTheGeek的答案，但我想我会插入一个可能在C＃4.0管道中的MSR技术的插件：Code Contracts

显而易见的答案是使用.Net基类库中包含的标准异常（ArgumentNullException，InvalidOperationException，NotImplementedException等），或者如果您觉得您的类的使用者可能需要创建您自己的特定异常了解他们为什么会收到例外的更多细节。

如果您的代码稍后将被使用，请务必在Xml评论部分列出可能的例外。

CLR会代表您填写堆栈信息，因此您需要做的就是抛弃这个坏孩子并让消费者处理后果。

因为您询问了语法：

    /// <summary>
    /// Summary: 
    ///     Does stuff.
    /// Exceptions:
    ///     ArgumentNullException:
    ///        args must be non-null
    /// </summary>
    /// <param name="args"></param>
    public static void DoStuff(string[] args)
    {
        if(args == null)
        throw new ArgumentNullException("args", "'args' parameter cannot be null.");

        ...
    }

在代码的生命周期内处理异常的最佳方法是什么？

4 个答案: