不确定这是讨论这个问题的最佳地点，因为它有点广泛，所以我会尝试缩小范围。
我的背景
回到前几天，我向我最近加入的团队经理询问了一些关于设计决策的问题。我正在为一家公司投资银行开展一个交易应用程序，并且有很多遗留代码（比如任何其他软件应用程序已经存在超过5年的变化）。
为了简化，这里似乎通常的做法是不抛出任何异常，不真正检查传递给方法或构造函数的参数。虽然我同意在某些情况下参数检查毫无价值，但当某些类型或值范围无法与您一起使用时，抛出异常可能会有所帮助。
人们在这里使用TDD而且我很好，但我不认为这种做法可以阻止一切。但吞噬异常并让其他灾难在沉默中发生绝不是更好，测试有助于防止这类问题发生，但并非总是如此。
这始终是一个环境问题，但在我过去，一个工作放异常帮助我的团队提高了代码质量，通过冒出我们得到的所有问题，主要是通过指出特殊值传递给某些实体，啊遗留代码......再次）并进行适当的重构。
问题/情景
假如我有一个类型B使用的类型A，一般来说，如果B在B的情况下滥用A（例如，值超出范围等），则在B面前抛出A的异常，那真的是一个不好的做法？它应该帮助B以正确的方式处理A（例如，将正确的参数传递给构造函数等）。当您查看.NET框架时，如果您滥用类，则会出现大量异常，然后会引发异常并让您知道它不应该与此相关。
同样，异常应该是例外的，但如果我们举一个解析IP地址的非常简单的实体或方法的例子，.NET Framework会轻轻地告诉你传递的字符串不适合：
var address = IPAddress.Parse(@"It makes sense =]");
// An unhandled exception of type 'System.FormatException' occurred in System.dll
// Additional information: An invalid IP address was specified.
问题
当然总是需要考虑很多上下文，并不是黑白分明，但你认为设计API是一种很好的方式来通知开发人员这些类无法使用这个值吗？ （除了文档，如果有的话）而不是例如当它无法工作时返回null，什么是最合法的？你怎么知道是否必须抛出异常或者只是返回false / null来表示它无法工作？
答案 0 :(得分：1)
只要在预期的工作流程中没有出现某些内容，就应该抛出例外情况。例如，如果使用不正确的参数调用方法（如在代码段中），则外部资源（如文件）不可用，或者应用程序处于不允许调用方法的状态。
异常允许其他开发人员决定异常在可以正常处理之前冒泡多远。此外，例外提供了有关出错的信息。
简单地返回null会引入一个问题，即必须先检查所有返回值是否为null，然后才能使用它们。否则，您可能会在导致整个应用程序崩溃的位置最终出现空引用异常。因此，返回null只应该比抛出异常更特殊地使用。