java - 动态类型方法中的奇数类型推断

Question

在处理配置管理器对象时，我想实现一种方法，该方法可以从管理器的内部索引中检索值并将其自动转换为所需的类型，从而无需显式转换。我认为使用 Java 在方法头中提供的泛型系统，这会很容易。因此，我将我的方法构造如下:

public <T> T getSettingAutocast(String key)
    {
        T retV = null;

        try {retV = (T) getSetting(key);}catch (ClassCastException ignored){}

        return retV;
    }

我通过使用它从设置注册表中提取文件来测试该方法，如下所示:

File f = configIO.getSettingAutocast("file");

其中注册表已在该关键地址处预加载了 File 对象。

这按预期工作。但是，如果我交换 File对于 Integer ，事情进展不太顺利 - 我得到了 ClassCastException 。在 Debug模式下查看它，T是方法开始时的正确类型，但是当调用强制转换时，它只会变成 getSetting 返回的任何类型。

我的印象是编译器试图推断 <T>来自目标对象(在本例中为 File 或 Integer )，而不是方法主体本身中的任何类型。如果有人能够提供有关编译器在方法方面如何处理类型推断的更多见解，我们将不胜感激。

Answer 1

您仍然传播 ClassCastException 的原因是此方法实际上并未进行强制转换。

类型删除后，赋值为:

retV = (Object) getSetting(key);

这当然会成功，因为一切都是对象(除非它是原始的，但那样你就无法在这里使用泛型)。

Actor 实际上被踢到了调用站点:

Integer = (Integer) configIO.getSettingAutocast("file");

(尝试反编译代码，您将看到一条 checkcast 指令)。

所以这就是抛出异常的地方，正如您应该从堆栈跟踪中注意到的那样。

I was under the impression...

不。通过使用这种模式，您将得到您应得的。强制转换是告诉编译器信任您的一种方式，因为您知道一些它不知道的类型信息；在这种情况下，您只是猜测类型，然后就猜错了。

返回对象，并检查调用站点的类型。是的，它会变得更难看；但丑陋的代码比漂亮但损坏的代码要好。仅仅进行强制转换这一事实就应该让您停下来考虑一下这里可能会出现什么问题，而不是将其隐藏在此方法中。