在重写java 1.4中的方法时如何避免“未使用的参数”警告？

In this code :

在这段代码中:

public class MyClass {
    private Object innerValue;
    public Object getInnerValue() {
        return this.innerValue;
    }
    public void setInnerValue(Object innerValue) {
        this.innerValue = innerValue;
    }
}

public class MyClassReadOnly extends MyClass {
    MyClassReadOnly(MyClass cls) {
        // Make a field by field copy
        super.setInnerValue(cls.getInnerValue());
    }
    public void setInnerValue(Object innerValue) {
        throw new UnsupportedOperationException(
                            "This is a read-only instance"
                        );
    }
}

The compiler complains rightly about the unused parameter(never read) innerValue in MyClassReadOnly.setInnerValue().

编译器正确地抱怨MyClassReadOnly.setInnerValue()中未使用的参数(从不读取)innerValue。

I don't want to disable this kind of warnings since it's quite useful usually, and I don't want to have any warnings either to have a high signal/noise ratio.

我不想禁用这种警告,因为它通常非常有用,而且我不希望有任何警告要么具有高信噪比。

I cannot use the @SuppressWarnings() construct as another question suggested since it's Java 1.4 only.

我不能使用@SuppressWarnings()构造作为另一个问题,因为它只是Java 1.4。

I thought about inserting dummy code like this, but it's not very satisfactory :

我想过插入像这样的虚拟代码,但它不是很令人满意:

public void setInnerValue(Object innerValue) {
    if (innerValue != null) { /* Do Nothing, but keep the compiler happy */ }
    throw new UnsupportedOperationException("This is a read-only instance");
}

5 个解决方案

#1

The warning is not the problem, I'm afraid that the design is.

警告不是问题,我担心的是设计。

Your current hierarchy violates Liskov's principle of substitution since a class receiving an instance of a MyClass expects setInnerValue to work, and may not handle this exception correctly. You can say that a read-and-write X is a type of readable-X, but you cannot say that a readable-X is a type of read-and-writable X.

您当前的层次结构违反了Liskov的替换原则,因为接收MyClass实例的类需要setInnerValue才能工作,并且可能无法正确处理此异常。你可以说读写X是一种可读的X,但你不能说可读X是一种可读写的X.

When I am faced with this sort of situation, I create an interface called IMyX with the reads, a subinterface called IMutableMyX with the writes, and then the actual class implements IMutableMyX and thus also IMyX. I am then very careful to only pass IMutableMyX when I need to, and pass IMyX in all other cases.

当我遇到这种情况时,我创建了一个名为IMyX的接口,其中包含读取,一个名为IMutableMyX的子接口和写入,然后实际的类实现了IMutableMyX,因此也实现了IMyX。我非常小心,只在需要时传递IMutableMyX,并在所有其他情况下传递IMyX。

I feel that it is better to use the compiler and types to restrict access than it is to count on runtime exceptions. It also makes your code a lot clearer, and forces you to explicitly downcast the interface when you do want write-access.

我觉得使用编译器和类型来限制访问比计算运行时异常更好。它还使您的代码更加清晰,并强制您在需要写访问时明确地向下转换接口。

I realize this does not answer your question about getting rid of the warnings. But warnings can either be suppressed, ignored, or addressed. An unused parameter is often a bad smell that indicates your method might not be doing what it's expected to do. Methods should only get essential parameters. If the parameter is not used, the parameter is not essential, and therefore something needs to be changed.

我意识到这并没有回答你关于摆脱警告的问题。但警告可以被抑制,忽略或解决。未使用的参数通常是难闻的气味,表明您的方法可能没有按照预期的方式进行。方法应该只获得必要的参数。如果未使用该参数,则该参数不是必需的,因此需要更改某些内容。

#2

I wouldn't play any "code tricks" just to make a compiler warning go away, hoping for the compiler to optimize away the tricks. In fact, is this compiler warning all that useful? I would just disable it. Once you are using Java 5, you can use @SuppressWarnings and reenable it.

我不会发挥任何“代码技巧”只是为了让编译器警告消失,希望编译器能够优化掉技巧。事实上,这个编译器警告是否有用?我会禁用它。使用Java 5后,您可以使用@SuppressWarnings并重新启用它。

IMO, it's a bad idea to enable all possible warnings, just because they exist, and then set out to make every single warning go away. Figure out which warnings actually make sense for your environment and disable the rest.

IMO,启用所有可能的警告是一个坏主意,因为它们存在,然后着手让每一个警告都消失。找出哪些警告实际上对您的环境有意义并禁用其余警告。

#3

I'm afraid you're stuck with dummy code. In C/C++, you could use a macro (#define _unused(x) ((void) x)), but (void) variable; isn't a valid statement in Java.

我担心你会遇到虚拟代码。在C / C ++中,您可以使用宏(#define _unused(x)((void)x)),但是(void)变量;不是Java中的有效语句。

If it makes you feel better, the compiler will likely optimize away the empty if-block.

如果它让你感觉更好,编译器可能会优化掉空的if块。

#4

You can safely enter lines like: innerValue = null; at the top of the function for all unused args. It will not affect the caller, but will keep the compiler happy.

您可以安全地输入如下行:innerValue = null;在所有未使用的args的函数顶部。它不会影响调用者,但会使编译器满意。

#5

If you're using Eclipse (?), you can turn on Parameter Is Never Read warnings, but ignore cases in overriding and implementing methods (which would solve this specific problem) and, separately, those documented with the "@param" tag (although of course that doesn't apply to Java 1.4). I would expect most other Java IDEs to have similar settings available.

如果您正在使用Eclipse(?),则可以打开参数从不读取警告,但忽略覆盖和实现方法(可以解决此特定问题)的情况,并单独记录使用“@param”标记记录的情况(虽然当然不适用于Java 1.4)。我希望大多数其他Java IDE都有类似的设置可用。

#1