开展会因RuntimeExceptions

假设我有一个方法或使用另一种方法或构造内部构造声明一个RuntimeException皆可抛声明。开展会因RuntimeExceptions

// Example: 
public MyClass(Object arg) { 
    setVar(arg); 
    // Not responsible for dealing with the exception 
} 

public void setVar(Object arg) throws MyRuntimeException { 
    if(!isValidArg(arg)) 
     throw new MyRuntimeException("Got you, evil argument!"); 
    // Do something 
}

在这种情况下，如果例如必要的前提条件未满足，则抛出RuntimeException。

问：包装方法/构造函数是否应该声明相同的异常，如果它的参数可能导致异常被抛出？

来源

2013-03-08 Samuel

如何在构造函数中调用实例方法？ – 2013-03-08 12:39:59

@LutzHorn你是什么意思？为什么他不应该这样做？除非该方法执行重度处理，否则不应该是个问题 – giorashc 2013-03-08 12:41:52

那么，构造函数应该构造实例。在完全构造之前调用此实例的方法让我感到奇怪。 – 2013-03-08 12:44:28

这真的取决于代码是在上下文中，如果你想的东西是自包含的，就像一个图书馆，你可能要赶上内部异常该类，只是为了使你的代码更清洁。

但是，如果你正在做的代码作为项目的一部分，那么我会像你说的，“携带抛出异常”，直到它没有任何意义，语义。

来源

2013-03-08 12:41:14 christopher

我认为“继续投掷直到没有意义，语义上”是有道理的。我想说明的是，捕获一个异常并不总是可能的，尽管你经常只能选择抛出一个检查异常，抛出运行时异常并声明它或不声明它。 – Samuel 2013-03-08 13:08:07

是的，同意了。 :) – christopher 2013-03-08 13:09:02

RuntimeExceptions抛出，而不需要把它列入了对既不的方法抛出签名。

你应该阅读this关于运行时异常

来源

2013-03-08 12:39:59 giorashc

这是正确的，他们不需要被抛出，但有时你想表示可以抛出异常，并让该类的用户决定是否他会处理它。例如，如果他传递的论点是基于用户的输入，并且可能是错误的，他可能会抓住它，但是如果他确定它是正确的，他就不会。 – Samuel 2013-03-08 12:46:59

如果是这种情况，那么为什么使用运行时异常？他可以很容易地使用检查的异常 – giorashc 2013-03-09 12:13:28

我认为有些人更喜欢抛出检查，有些人更喜欢抛出未经检查的异常。在我的情况下，这不是一个选择点，运行时异常正在抛出，我试图找到最好的方式来处理它在一个不负责处理的包装方法。 – Samuel 2013-03-09 16:08:52

我会声明它，如果它不应该在包装方法内处理 - 与检查相同例外。

无论如何，有这样的暗示甚至对于未检查的异常的方法。客户将决定是否需要处理。

来源

2013-03-08 12:44:16

否，运行时异常不会被检查，即编译器不会强制您处理它们。但作为一个良好的编程习惯，你可以处理异常，如

public MyClass(Object arg) { 
    try{ 
    setVar(arg); 
} 
catch(MyRuntimeException exp){ 
    // code if exception arises 
}

来源

2013-03-08 12:47:21 navyad

这是真的，但构造函数可能不负责处理异常。 – Samuel 2013-03-08 12:48:50

这是一个糟糕的主意*通常*在构造函数中捕获像这样的异常，除非您非常确信您可以以一种合理的方式来完成对象的构造。如果没有，最好让异常传播给调用者。 – Perception 2013-03-08 12:52:05

如果你从构造函数调用一个方法，并且该方法可能会抛出一个异常，那么你可能不确定你的对象是否会被构造 – navyad 2013-03-08 12:54:30

开展会因RuntimeExceptions

回答

相关问题