C# 在低级库函数中处理异常

我们正在编写一个低级函数库（主要是模拟一些Matlab sig处理函数）——基本上是静态对象上的一组静态方法。这将在更高级别的框架中使用（我们也正在编写）。框架和低级库都是内部使用的（不是公共的）

对于这种情况，什么是好的异常处理模型？我看到的两个选项是：
1.在低级库中没有异常处理-让零除etc异常在消费框架中冒泡并处理它们。
2.在每个低级函数中，系统地检查参数中可能产生溢出、除零、意外根-ve num等的值，并抛出ArgumentException和有关问题的诊断文本

做2。提供超过1的优势。这就证明了附加代码的合理性？我的感觉是，这可能使问题发生的位置更容易确定。

---

是否有理由这样做或那样做？答案在很大程度上取决于所讨论的库：

• 它是由您的Oragnization独家使用，还是公开发布
• 是否存在任何安全隐患
• it失败的商业成本是多少

一般来说，在“public”*API上执行参数验证是一种很好的做法。如果发生故障，您将如何处理取决于您自己，但是抛出带有信息性文本描述的ArgumentException是一个好主意，对使用库的开发人员很有帮助

有许多资源在各种场景中讨论该主题，包括一个关于程序员的类似问题：。忽略它被标记为一个副本-它不是真的

如果库要向公众开放，不验证参数可能会导致各种安全漏洞，因为像不绑定检查数组和不验证指针这样的事情可能会导致恶意代码以最意想不到的方式和位置被注入

关于他们的CRT库功能，微软有几点要说：

我（个人）的建议是选择选项2：验证参数并抛出有意义的异常

---

*“公共”的含义可以解释。

2。这对于帮助程序员使用您的库非常重要。当这样的程序员对库了解不够时，好的异常非常有用。你还避免了一个“你的代码糟透了”的支持电话，而不是你想要的那种。它不是1的替代品，您不太可能涵盖所有可能的故障，在某些情况下，检查的成本可能会过高。1和2都适用。这是一个相当不错的评论答案。谢谢。这个链接的问题很有趣——前两个答案几乎都是对号入座的，但它们的票数相似（16:13）——似乎并不明确，正如你所说的，这取决于上下文。@Bob因为你在“模拟”Matlab函数，你可能应该包括Matlab处理边界检查的方式。（我在这里对仿真的定义有点迂腐。）