Java中异常的后缀Exception


19

在异常类上指定Exception的后缀感觉对我来说像是代码的味道(冗余信息-名称的其余部分表示错误状态,并且它继承自Exception)。但是,似乎每个人都这样做,这似乎是一种好习惯。

我想了解为什么这是个好习惯。

我已经阅读并阅读了以下问题:为什么异常通常在类名中带有后缀异常

问题是针对PHP,而响应可能对Java有效。还有其他论点吗?或者真的和区分它们一样简单吗?

如果我们从上一个问题中选取示例,那么java中是否确实存在名称FileNoFound并非例外的类?如果可能的话,是否应该加上后缀Exception

纵观eclipse的快速层次结构Exception,可以肯定的是,它们中的绝大多数确实有例外后缀,但也有一些例外。javassist是一个库的示例,该库似乎有一些没有后缀的异常-例如BadByteCodeBadHttpRequest等。

BouncyCastle 是另一个lib,但有例外 CompileError

我在Google上搜索的信息也很少。


2
“所有例外都应该带有Exception后缀,还是应该为例外例外设置例外?” ;)
tdammers

2
实际上,Error就像Exception(请参阅OutOfMemoryError)一样,但是它们的意思是难以恢复的东西(因此您几乎从不处理它们)
棘手怪胎

1
另外,我听说一般规则是“类应该是名词,方法应该是动词(动作)”。FileNotFound ArrayIndexOutOfBoundsOutOfMemory更多的观察/描述,但随后应用于名词Exception
MikeTheLiar 2013年

Answers:


27

Landei的答案是一个很好的答案,但也有语法上的答案。 类名应为名词。什么是“内存不足”?什么是“ FileNotFound”?如果您将“ Exception”视为名词,则描述符是形容它的形容词。这不只是任何一个Exception,而是一个FileNotFoundExceptionOutOfMemory除了去商店购买“蓝色”外,您无需再捉住任何东西。

如果您将代码作为句子阅读,也会显示以下内容:“ Try正在执行...和catch OutOfMemory Exceptions


1
引用文章“尝试使用名词,因为类通常代表现实世界中的事物”。但是这种情况有例外吗?对我而言,它们更像是编程伪像,代表错误消息。“您将获得OutOfMemory例外”比“您将获得例外”读起来更好OutOfMemoryException,不是吗?
greg0ire

1
@ greg0ire-您应该尝试使用“您将得到一个” OutOfMemoryException。就是说,我们也有PIN码和ATM机,因此OOME异常不会那么罕见。
Bobson,

我认为您在这里提出的观点确实是最好的(关于名称冲突的观点已不再存在,这要归功于名称空间,至少在php中如此)。关于这一切,我还有很多话要说,并将尽快发布答案。
greg0ire 2016年

做完了!你怎么看?
greg0ire

@Bobson我建议阅读《名词的王国》。我们不需要一切都成为名词。为什么“你会得到一个OutOfMemoryException”时,它可以简单地将“你内存不足”?我们不使用Class后缀(DogClassCatClassXmlReaderClass,...)。
Matthieu Napoli

6

我觉得异常(和错误,理论上其他ThrowableS)从之类的东西接口或枚举不同(通常不作为后缀):他们通常是非常明确和有限的目的,他们有专门的语言结构中使用(trycatchthrowthrows),并按照特殊规则(例如检查VS unchecked异常,没有仿制药)。在某种程度上,它们不仅是碰巧用作异常的类,而且是通过类的手段实现的异常机制。

因此,如果您在处理异常时不认识到异常,那么通常情况就很不对劲了(枚举或接口之类的情况也不是这种情况)。因此,我认为与“正常”课程的这些差异足以引起视觉提示。


1
听起来与我矛盾。如果异常是如此特殊并且以特殊方式使用并且明显地可以识别,那么为什么需要视觉提示呢?
Michael Borgwardt

@MichaelBorgwardt-我想他是说,因为它们很特殊并且以特殊方式使用,所以它们应该具有明显的视觉线索。话虽这么说,我不知道您是否还能抛出ExceptionJava中没有继承的东西-C#中不能。如果不能的话,那么我就不会想到这样的情况:“应对异常,并且[不]这样认识”。
Bobson

您也不能用ThrowableJava 抛出非符号。但是,您不仅可以在try- catch设置中处理异常,例如,当您对复杂对象进行某种验证时(当您想知道所有相关问题,而不仅是第一个问题时),您可能会收集异常。在这种情况下,您应该意识到您可以重新抛出列表中的所有内容,因此调用它们ValidationIssue而不是会很不好ValidationException
兰代

0

但是,似乎每个人都这样做,这似乎是一种好习惯。

是的,每个人的确都这样做,所以这是一种实践,但是仍然很好吗?有几个人在质疑:

  • http://mnapoli.fr/approaching-coding-style-rationally/(例外后缀§上下文:php)
  • 链接的视频https://vimeo.com/album/2661665/video/74316116(跳至53:00,上下文:php)激发了这篇文章,并指出每次使用异常时,您都有一个关键字已经表明这是附近的一个例外
  • http://verraes.net/2013/10/verbs-in-class-names/显示了@Bobson答案中的语句可能不是绝对的,并指出有时后缀适用于应用程序或基础结构级别的例外,有时您应该尝试保存此长后缀所采用的字符,以表达更精确和有意义的内容。仅当您使用一种文化来将异常用于业务规则违例的语言时,这一点才有意义。
  • 您提供的SO链接说明了名称冲突,但是现在,我们有了名称空间,不是吗?

这是一个Java问题,而不是PHP问题。习语在语言之间是不同的。也就是说,我非常不同意您在第三个链接中的引用: “异常可能类似于事件,...细微差别是不希望发生的事件,它警告某些操作与例如业务规则不一致有效。” 也许PHP对此有所不同,但是在我看来,异常应该是例外。如果以某种预期的方式违反了业务规则,则您的常规逻辑应进行处理-这不是常规行为的例外
Bobson,2016年

您可能是对的,因为它会根据每种语言的不同而有所不同:请参见有关python的以下线程:gossamer-threads.com/lists/python/python/796627。php和python显然不是以性能为中心的,这也许就是为什么与java有这种区别(以性能为中心,对吗?)。如果在正确处理业务规则冲突之前,在调用堆栈中需要跨越多个层次,则异常最好是IMO。它还使返回类型更加一致(返回的类型始终相同,而不是false或true)。我会将此答案修改为考虑因素
greg0ire '16
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.