慕仰1329654
你链接到的“问题”似乎是在描述这种情况:SomeObject so;try {
// Do some work here ...
so = new SomeObject();
so.DoUsefulThings();} finally {
so.CleanUp(); // Compiler error here}注释者的抱怨是编译器在finally一节,声称so可能是未初始化的。然后,注释提到了另一种编写代码的方法,可能如下所示:// Do some work here ...SomeObject so = new SomeObject();try {
so.DoUsefulThings();} finally {
so.CleanUp();}注释者对该解决方案不满意,因为编译器随后说代码“必须在尝试中”。我猜这意味着一些代码可能会引发一个不再被处理的异常。我没有把握。我的代码的两个版本都不处理任何异常,因此第一个版本中任何与异常相关的操作在第二个版本中都应该是相同的。无论如何,第二个版本的代码是对,是这样写它的方法。在第一个版本中,编译器的错误消息是正确的。这个so变量可能未初始化。特别是,如果SomeObject构造器失败,so将不会被初始化,因此尝试调用它将是一个错误。so.CleanUp..始终输入try剖面后您已经获得了finally部分最后确定。这个try-finally块之后的so初始化只来保护SomeObject例如,不管发生什么事情,都要把它清理干净。如果有其他需要运行的东西,但它们与SomeObject实例被分配了属性,那么它们应该进入另一个 try-finally布洛克,可能是我展示的那个。在使用前需要手动分配变量并不会导致真正的问题。这只会导致一些小麻烦,但是您的代码会更好。您将拥有范围更有限的变量,并且try-finally不试图保护太多的障碍。如果局部变量具有默认值,则so在第一个例子中null..那根本解决不了任何问题。而不是在finally布洛克,你会有一个NullPointerException潜伏在那里藏无论在代码的“在这里做一些工作”部分可能发生什么其他异常。(或在finally节自动链接到以前的异常?我不记得了。即使如此,你也会有一个额外的例外,就像真正的例外。)