我担心这是运行时异常所以应该谨慎使用它 标准用例:
void setPercentage(int pct) {
if( pct < 0 || pct > 100) {
throw new IllegalArgumentException("bad percent");
}
}
但这似乎会迫使以下设计:
public void computeScore() throws MyPackageException {
try {
setPercentage(userInputPercent);
}
catch(IllegalArgumentException exc){
throw new MyPackageException(exc);
}
}
让它回到被检查的例外。
好的,但让我们继续。如果输入错误,则会出现运行时错误。首先,这实际上是统一实施的相当困难的政策,因为你可能必须进行相反的转换:
public void scanEmail(String emailStr, InputStream mime) {
try {
EmailAddress parsedAddress = EmailUtil.parse(emailStr);
}
catch(ParseException exc){
throw new IllegalArgumentException("bad email", exc);
}
}
更糟糕的是 - 在检查0 <= pct && pct <= 100
时,客户端代码可能需要静态执行,但对于更高级的数据(如电子邮件地址)则更是如此,或者更糟糕的是,必须根据数据库进行检查,因此通常客户端代码无法预先验证。
基本上我所说的是我没有看到使用IllegalArgumentException
的有意义的一致政策。它似乎不应该被使用,我们应该坚持我们自己检查的例外。扔这个的好用例是什么?
答案 0 :(得分:69)
IllegalArgumentException的api文档是:
抛出以表明方法已被传递为非法或不恰当的参数。
从how it is used in the jdk libraries看,我会说:
在输入进入作品之前抱怨显然输入错误似乎是一种防御性措施,并且会在失败的情况下使用无意义的错误消息导致某些事情失败。
它用于抛出一个经过检查的异常会很烦人的情况(虽然它在java.lang.reflect代码中出现,但是对于那些关注异常抛出的荒谬级别的关注却没有表观的)。
我会使用IllegalArgumentException对常见实用程序执行last-ditch防御性参数检查(尝试与jdk使用保持一致),其中期望坏参数是程序员错误,类似于NPE。我不会用它来实现业务代码中的验证。我当然不会将它用于电子邮件示例。
答案 1 :(得分:19)
在谈论“输入错误”时,您应该考虑输入的来源。
如果您无法控制用户或其他外部系统输入的输入,您应该期望输入无效,并始终对其进行验证。在这种情况下抛出一个检查过的异常是完全可以的。您的应用程序应通过向用户提供错误消息来“恢复”此异常。
如果输入源自您自己的系统,例如您的数据库或应用程序的某些其他部分,您应该能够依赖它有效(它应该在它到达之前已经过验证)。在这种情况下,完全可以抛出一个未经检查的异常,例如IllegalArgumentException,它不应被捕获(通常你永远不应该捕获未经检查的异常)。程序员的错误是无效值首先到达那里;)你需要修复它。
答案 2 :(得分:12)
抛出运行时异常&#34;谨慎&#34;并不是一个好的策略 - 有效的Java建议您在可以合理地期望恢复时使用已检查的异常。 (程序员错误是一个具体的例子:如果一个特定的情况表明程序员错误,那么你应该抛出一个未经检查的异常;你希望程序员有一个堆栈跟踪逻辑问题发生的地方,而不是试图自己处理它。)< / p>
如果没有恢复的希望,那么随意使用未经检查的例外;没有必要抓住它们,所以这很好。
但是,从您的示例中可以看出这个示例在您的代码中的情况不是100%。
答案 3 :(得分:5)
如oracle官方教程中所述,它声明:
如果可以合理地期望客户从异常中恢复, 使它成为检查异常。如果客户端无法做任何事情来恢复 从异常中,将其作为未经检查的例外。
如果我有一个应用程序使用JDBC
与数据库交互,我有一个方法将参数作为int item
和double price
。从数据库表中读取相应项的price
。我只是将item
购买的总数乘以price
值并返回结果。虽然我总是确定在我的结尾(应用程序结束),表中的价格字段值永远不会是负数。但是,如果价格值出现负面怎么办?它表明数据库方面存在严重问题。也许是运营商错误的价格进入。这是调用该方法的应用程序的其他部分无法预测并且无法从中恢复的问题。它是您数据库中的BUG
。因此,在这种情况下应该抛出IllegalArguementException()
,这将表明the price can't be negative
。
我希望我已经明确表达了我的观点..
答案 4 :(得分:5)
任何API都应该在执行之前检查任何公共方法的每个参数的有效性:
void setPercentage(int pct, AnObject object) {
if( pct < 0 || pct > 100) {
throw new IllegalArgumentException("pct has an invalid value");
}
if (object == null) {
throw new IllegalArgumentException("object is null");
}
}
它们代表应用程序中99.9%的错误,因为它要求不可能的操作,所以最终它们是应该使应用程序崩溃的错误(因此它是一个不可恢复的错误)。
在这种情况下,在快速失败的情况下,您应该让应用程序完成以避免破坏应用程序状态。
答案 5 :(得分:1)
将IllegalArgumentException
视为前提条件检查,并考虑设计原则:公共方法应该知道并公开记录自己的先决条件。
我同意这个例子是正确的:
void setPercentage(int pct) {
if( pct < 0 || pct > 100) {
throw new IllegalArgumentException("bad percent");
}
}
如果EmailUtil不透明,这意味着有些原因无法向最终用户描述前置条件,那么检查的异常是正确的。第二个版本,针对此设计进行了更正:
import com.someoneelse.EmailUtil;
public void scanEmail(String emailStr, InputStream mime) throws ParseException {
EmailAddress parsedAddress = EmailUtil.parseAddress(emailStr);
}
如果EmailUtil是透明的,例如,它可能是所讨论的类所拥有的私有方法,IllegalArgumentException
是正确的,当且仅当其前置条件可以在功能文档。这也是一个正确的版本:
/** @param String email An email with an address in the form abc@xyz.com
* with no nested comments, periods or other nonsense.
*/
public String scanEmail(String email)
if (!addressIsProperlyFormatted(email)) {
throw new IllegalArgumentException("invalid address");
}
return parseEmail(emailAddr);
}
private String parseEmail(String emailS) {
// Assumes email is valid
boolean parsesJustFine = true;
// Parse logic
if (!parsesJustFine) {
// As a private method it is an internal error if address is improperly
// formatted. This is an internal error to the class implementation.
throw new AssertError("Internal error");
}
}
这种设计可以采用任何一种方式。
ParseException
。这里的顶级方法名为scanEmail
,暗示最终用户打算发送未经验证的电子邮件,因此这可能是正确的。IllegalArgumentException
。虽然没有&#34;检查&#34; &#34;检查&#34;移动到记录该功能的Javadoc,客户端应该遵守该功能。 IllegalArgumentException
客户无法事先告知他们的论点是非法的。 关于IllegalStateException的说明:这意味着&#34;此对象的内部状态(私有实例变量)无法执行此操作。&#34;在客户端调用无法知道对象的状态不一致的情况下,最终用户无法看到私有状态,因此松散地说它优先于IllegalArgumentException
。虽然它比检查异常更受欢迎但我没有一个很好的解释,尽管例如初始化两次或丢失未恢复的数据库连接等都是例子。