在我现在所在的公司，代码中有很多地方会抛出OurCompanyRuntimeException（其中OurCompany是公司的实际名称）。据我所知，这个异常被描述为“我们在这家公司写的代码抛出的运行时异常。”
我对Java很新，但我认为异常类型应该反映 出错了什么，而不是其代码引发了异常。例如，IllegalArgumentException意味着有人将非法参数传递给了某些东西。如果在Sun编写的代码中传递了非法参数，那么就不会有SunIllegalArgumentException，然后是IBMIllegalArgumentException - 这将是愚蠢而毫无意义的，对吧？如果您想知道抛出异常的位置，可以查看堆栈跟踪。我理解想要扩展RuntimeException（这样你就没有尽可能多的尝试/捕获或“抛出”），但为什么不创建解释发生了什么的子类，而不是公司的代码发生在哪里呢？
以前有没有人曾经使用过OurCompanyRuntimeException这个想法，或者知道为什么他们会这样做？
答案 0 :(得分：6)
听起来像你在内部代码库中发现的通常的定制代码废话。我怀疑，如果你问一下，OurCompanyRuntimeException根据一个没有人敢提出疑问并且早已移动的高级家伙的错误逻辑而使用了{{1}}的一些法令 - {{3}的故事想到了。
我同意你的看法，例外的名称应该表明发生的错误。
答案 1 :(得分：2)
帮助读取堆栈跟踪，这是肯定的。即当扫描很多行'由'引起'时，有助于看到它发生在你抛出的东西上，而不是内部的东西，比如容器。
还允许您执行自定义操作作为throwable的一部分 - 例如写一个特殊的日志，等等。
答案 2 :(得分：2)
是的，我也遇到过，但对我来说也没有意义。我的猜测是，这些公司在采用Java之后很早就写了这个例外而没有正确理解异常抛出和处理是如何工作的（就像Nick已经说过的那样......高级程序员没有人敢提出质疑）。 如果公司认为需要创建自己的异常类（例如，对于公司特定的日志记录porpuses），则永远不应该直接抛出此异常（使其成为抽象）。我会得到具体的问题来描述异常，或者只是遵循Spring Framework的异常处理/抛出的想法。
答案 3 :(得分：1)
这是一个糟糕的概念。例外情况应该针对用例。
好的，如果公司确实产生了很多错误的代码/产品，他们可能会使用这种类型的例外作为广告;）
答案 4 :(得分：1)
您的公司可能会将代码添加到现有项目中，例如开源代码库，并且可能只是添加了很少的代码。因此，为了跟踪公司开发人员发生的错误，他们认为他们将拥有自己的异常类来区分之前存在的错误和扩展引起的错误。这样，他们可以只关注由公司开发人员引起的那些，并且可能要求原始源代码维护者修复其他的。
随着时间的推移，当人们通过内部开发开发了足够大的代码库时，您可以添加更多异常并删除CompanynameRuntimeException altogother。此外，他们可能会更熟悉开发人员的专业水平，允许他们将所有错误视为一个错误，而不是更加可疑地查看公司开发人员造成的错误。
答案 5 :(得分：1)
将此作为特定异常的基类是非常有意义的。抛出一个特定的异常并捕获基类。
此外，它可能允许携带原因（REAL异常）以及附近的其他信息。这对于创建用于记录的诊断输出非常方便。
答案 6 :(得分：1)
看起来非常愚蠢，日志记录输出或堆栈跟踪会向您显示违规类是谁，因此解释不会洗。同样看起来很危险，好像鼓励人们抛出OurCompanyRuntimeException他们正在抛出RuntimeExceptions，它不会强制调用者处理它们并且可以删除你的应用程序。
我同意你的看法，例外情况应反映其背后的原因。我已经看到一个自定义异常作为层次结构的根，虽然它可能应该是抽象的，所以你需要创建一个特定的扩展来使用它，它绝对不应该是RuntimeException。
答案 7 :(得分：0)
拥有一个通用的公司范围的异常类并不是一个坏主意，就像你描述更具体的异常情况一样。一个答案已经提到了能够专门捕获内部代码异常并忽略/传递核心java或第三方库代码中的异常的能力。这里的关键点是更具体的例外应该从这个例外继承。很少需要抛出一个通用的公司命名的异常，几乎从不推荐。