沮丧地抛出通用exception？
为什么不鼓励抛出generics（java.lang.Exception）exception，当它通常足以处理方法中的大多数条件失败时？ 我理解，如果一个方法可以抛出多种类型的exception，那么抛出exception的特定子类可能会略微澄清处理，但在一般的失败/成功情况下，我认为Exception的function绰绰有余。
问题是Exception也是RuntimeException的超类，它包含一些不应该被捕获的东西，因为它表明编程有问题，而不是由上下文引起的exception情况。 在正常情况下，您不希望捕获BufferOverflowException或UnsupportedOperationException。 此外，抛出单独的Exception类型可以让调用代码控制如何处理每个类型。 使用新的多捕获function在Java 7中减少了Boilerplate。
如果抛出更多特定exception，则不会阻止任何调用代码在一个Exception捕获块中处理所有Exception 。 更具体的是更多地记录错误发生的类型，使程序员更容易分别处理它们。
此外，通过抛出“exception”本身，您基本上告诉调用者您的代码，他们不能排除任何类别的exception。 可能会发生IOException可能会发生NumberFormatException等。
一如既往：这取决于。
我认为您向其他人公开的API之间存在差异。 这可能会存在一段时间。 在这种情况下，您不知道调用者最适合他的案例。
另一方面，始终只有您自己内部使用的代码。 抛出一般exception可能就足够了。 但请记住，您可能希望稍后更改某些exception处理。 当所有错误情况一起被破坏时，这将更难。
通常，您希望知道应用程序中发生了什么，并且只捕获特定exception，并且当您获得未专门定位的exception时，让程序失败（或执行顺序更高）。 捕获exception将捕获所有这些，在某些情况下，您不会知道您的程序失败。
Dittos到GH。 我会使用“空指针exception”和“内存不足exception”作为您可能不会在真实应用程序exception的同一块中捕获的exception类型的更明显示例。
我还要补充一点，为未来的可扩展性做一点努力是值得的。 如果你在所有地方抛出通用exception，并且稍后你决定需要捕获一些exception而不是其他exception，那么回过头来改变它们可能是一个很大的痛苦。 但是，如果您只是创建所需的例外，那么这并不是什么大问题。 创建一个新的exception类，只接受带有消息的构造函数，需要什么，5行代码？ 这是对未来的良好投资。
像编程中的许多东西一样，这是一个你走多远的问题。 我通常在我工作的几乎每个项目中都创建一个相当通用的“BadInputException”，并在用户输入失败validation标准时抛出它。 然后我可以捕获BadInputException并在屏幕上抛出消息。 如果我创建一个复杂的类来抛出exception数据的exception，那么我通常会为它创建一个exception类。 就像我创建一个“TalkToDatabase”类一样，我将创建一个“TalkToDatabaseException”。 （如果有多种例外情况，我知道我想要抓住，但至少是那个。）
顺便说一下，我不知道你是否在想这个，但我强烈反对检查错误信息的文本，以确定错误的类型。 我已经看过程序，它们会在所有地方抛出genericsexception，然后在catch块中，它们的代码就像
// Very bad idea! Don't do this! catch (Exception ex) { if (ex.getMessage().equals("Invalid foo")) ... handle bad foo ... else if (ex.getMessage().equals("Plugh is over maximum")) ... handle bad plugh ... ... etc ... }
对这些案例单独制定例外会好得多。 处理不仅会更有效率，而且假设您执行上述操作并且稍后有人出现并决定将消息更改为“Foo无效”？ 该程序仍将编译，但它将无法正常工作。