我正在使用Utility类,此类中的一个方法接受内容(String
)和id(int
)作为参数,转换内容a将其返回给客户端。
我正在验证输入(内容不能为空,id必须为正),在此阶段我不确定如果不满足其中一些期望该怎么办。最好返回原始的,未修改的内容String
或抛出一个适当的异常,告诉客户端输入是否有效?
public String prepareContent(String content, long taskItemId) {
if (Validator.notBlank(content) == false || Validator.isPositive(taskItemId) == false) {
// what to do here? return content or throw an exception?
}
// some modification stuff....
return content;
}
处理这些情况的最佳方法是什么?
编辑:例如,Apache StringUtils库中的replace方法返回未修改的原始值而不是抛出异常。这个目的是什么......?
public static String replace(String text, String searchString, String replacement, int max) {
if (isEmpty(text) || isEmpty(searchString) || replacement == null || max == 0) {
return text;
}
// omitted...
}
答案 0 :(得分:2)
当一个错误的参数传递给你的方法时,惯例是抛出IllegalArgumentException
(RuntimeException
) - 有关详细信息,请参阅API - 您也可以将其扩展到您的喜好。
返回未经修改的内容可能不是一个好主意,因为它可能会导致处理链中的错误。
但是,如果操作允许返回的Object
在参数或值中与参数相等,例如如果找不到替换参数,那么您可能希望返回参数。
最终,您的方法的一个好的javadoc规范将胜过您的实现可能导致的任何歧义。
答案 1 :(得分:1)
很容易声称它取决于你可以在决策中应用一些逻辑。何时抛出异常或何时导致未修改的输入的决定可以基于假设。
如果我们有一个算法形成给定的输入产生输出和输出等于输入,换句话说没有效果,那么就不必执行算法。
如果输入参数不允许以确定的方式操作算法,则应报告错误。
这两句话可以帮助您决定何时投掷以及何时返回未修改的值。
来自Apache的传递示例。
方法replace(String text, String searchString, String replacement, int max)
,任务是替换text
值与searchString
匹配且值为'replacement',并且操作应执行max
次。
从这个我们可以在确定性(总是相同)的方式状态。
如果文本的值为空,则不能进行替换。因此,无论其他参数是什么,结果都将始终相同。
如果searchString
的值为空,我们将无法找到任何替换,因为不会发生替换。
如果replacement
的值为null
。我们处理开发人员的选择,因为你不能将null
放入字符串中,所以抛出异常是公平的。但出于同样的原因,不会发生任何变化。
如果max
的值等于零,则不会进行替换。
以上所有语句都映射到方法用于返回未更改输入的条件。它们是确定性的,因为它们总是如此。
如果是您的方法,您有一些输出必须符合的规则。那些是不可能是空的,必须是积极的。因此,如果输入为正且修改不会改变,那么您可以按原样返回。
答案 2 :(得分:0)
在设计API时,您不仅要考虑方法的作用,还要考虑其他人如何使用您的方法。
考虑一下,如果未通过验证,是否需要通知方法的调用者,或者无论如何都可以继续使用未修改的内容。
如果他们可以继续使用未经修改的内容,请将其退回。
如果没有,您的方法必须通知调用者验证未通过并返回,异常是完美的方法。
如果验证是程序中的常见任务,则另一个选项是使用类进行验证而不是方法。
public class PrepareContent {
public static boolean isValid(String content, long taskItemId) {
// ...
}
// @returns InvalidParameterException if the input is not valid
public static String prepareContent(String content, long taskItemId) {
if (!isValid(String content, long taskItemId) throw new InvalidParameterException();
// ..
}
}
代码可以改进,但只是提供了如何做的不同的想法。如果您为验证类使用接口,那么它将易于扩展和修改。