是否存在抛出异常的Java方法的特定命名约定?

时间:2009-07-23 01:45:07

标签: java coding-style method-names

我很想添加一个类似“Ex”的后缀,以区分那些抛出异常的方法(带有相似的签名)。

有这样的惯例吗?

11 个答案:

答案 0 :(得分:18)

是的,您将它们命名为与不这样做的方法相同。

异常规范不够吗?

编辑:如果您有类似抛出/不投掷的方法,我建议使用Parse / TryParse模式(Parse替换为操作)。 .NET Framework经常使用它(Dictionary<T,K>.TryGetValueMonitor.TryEnterint.TryParse等等。)

修改:Coding Horror: TryParse and the Exception Tax

答案 1 :(得分:13)

不要那样做。

这就像问“有两个字符串作为参数的方法的命名约定”。

Java检查了异常,这意味着无论如何都需要声明它们。 因此,您可以轻松查看是否会抛出异常以及异常类型。 在不添加异常处理代码的情况下,甚至无法编译调用该方法的代码。

更新:您的意图似乎是让方法检查某个条件是否为真,但您不想返回false,但如果条件不满足则抛出异常,这样你也可以传达解释信息(在例外中)。我认为“断言”或“确保”的前缀是有道理的:

 // instead of
 if (! isAuthenticated())
    throw new NotAuthenticatedException("not sure why at this point...");

 // you do
 assertAuthentication();
 // which will throw NotAuthenticatedException("proper explanation") inside

答案 2 :(得分:8)

为什么你会用Java做这样的事情?它已经内置了该语言的异常说明符。编译器将阻止您调用显式抛出异常的方法,而不需要您采取某些操作来处理或允许异常传播?

答案 3 :(得分:2)

异常是Java中方法签名的一部分,因此这样的命名约定将是多余的。

答案 4 :(得分:2)

匈牙利语表示抛出异常的方法?奎尔恐怖!

您的意思是选中或未选中的例外情况吗?为什么你想要这样做呢?

当你考虑它时,你必须将你的约定添加到每个方法中,因为总有可能出现错误或NPE或其他可能出错的事情。

当您检查异常时,“throws”子句就足够了,并且对于未经检查的异常,上帝的绿地没有任何好处。

不要这样做。请。

答案 5 :(得分:2)

如果你需要区分这些方法,我相信你可以在命名中不使用后缀或任何东西,这是(正如其他人指出的那样)非常可怕。

为什么:

boolean authenticate(String username, String password);

和(说)

void authenticateEx(String username, String password) throws WhateverException;

通过传达实际意图,实际上可以使其成为名称的一个有意义的部分:

void ensureCanAuthenticate(String username, String password);

// or

void assertValidCredentials(...);

// or

void authenticateOrDie(...);

......或任何其他(可能更好的)名称实际上传达意图而不是依赖于混乱的后缀。

答案 6 :(得分:1)

没有惯例,添加ex将使名称更难以阅读和丑陋寻找普通的java程序员。

但有时候我可以想象,如果可以引发异常的方法添加尝试,会使代码更容易理解。特别是如果他们没有被检查。

它不一定是丑陋的东西,就像它可以在许多c / c ++程序中找到的那样你使用_name或mName作为成员或iValue作为整数。 但在java中也有一些约定。 如果一个方法将返回一个整数,则前缀为... set,get和test是最常用的示例。所有这些都记录在方法头文件中,通过返回类型注释等...但是在函数名称中添加一个单词可以更容易,更快速地阅读和理解。

为什么不尝试让程序员阅读你的代码时潜意识暗示这种方法可能会引发异常。像tryCopyFile而不是tryWriteFile。

答案 7 :(得分:0)

没有我知道的。

在我看来,这样的事情唯一有意义的是单元测试用例(例如,testFooExpectingException())。但那并不是你所说的。

答案 8 :(得分:0)

没有这样的约定,因为无论您是否声明异常,每个方法都可以抛出异常。在IDE工具提示的这个时代,它也有点多余(当然,除非你没有使用IDE)。

我很想知道为什么你很想使用这样的命名约定。

答案 9 :(得分:0)

每隔一段时间你就会遇到这样一种情况:有一个像getSafely()这样的方法名称是有意义的(在实际值无效的情况下返回一个默认值,对于没有的代码)不太关心真实值与占位符之间的关系)或其相反的getOrBlowUp()(对于失败快速的代码,其中缺失值在技术上是可行的,但表示代码中应该设置值的错误。)

但这里的重点不是“方法2抛出异常,方法1没有” - 因为,如上所述,任何代码都可以抛出RuntimeException。关键是这两种方法具有不同的错误处理语义,特定于不同的用例,方法名称试图捕获的内容。

即便如此,如果您只是逃避一种行为或另一种行为,并且调用方法get(),代码通常会更清晰。

这里有用的并行可能是匈牙利表示法中的the distinction between Systems Hungarian and Apps Hungarian。 (另请参阅Joel on Software上的this piece on coding conventions。)

  • 系统匈牙利语只是告诉您变量的类型,因此整数count变为iCount。这是匈牙利符号和恕我直言的最常见形式,它是(1)对于现代IDE而言毫无意义,(2)如果有人在不重命名变量的情况下更改类型声明,则可能具有欺骗性。
  • 应用程序匈牙利语告诉您变量的目的,那么表示数据行的整数(或简短或序数ID对象,或其他什么,谁在乎?)index变为{{ 1}},表示注释列的drIndex变为index。这更有用,也不太可能造成麻烦。

调用您的方法acIndex是匈牙利系统。

答案 10 :(得分:0)

一般不要添加到方法名中。

改为添加投掷。

int parseInt(String s, int radix) throws NumberFormatException

但我个人喜欢 getter 例如

    getFieldsOrThrow(java.lang.String key)
    getFieldsOrDefault(java.lang.String key, Value defaultValue)

https://developers.google.com/protocol-buffers/docs/reference/java/com/google/protobuf/Struct