你鏈接到的“問題”似乎是在描述這種情況：
SomeObject so;try {
// Do some work here ...
so = new SomeObject();
so.DoUsefulThings();} finally {
so.CleanUp(); // Compiler error here}注釋者的抱怨是編譯器在finally一節(jié)，聲稱so可能是未初始化的。然后，注釋提到了另一種編寫代碼的方法，可能如下所示：
// Do some work here ...SomeObject so = new SomeObject();try {
so.DoUsefulThings();} finally {
so.CleanUp();}注釋者對該解決方案不滿意，因?yàn)榫幾g器隨后說代碼“必須在嘗試中”。我猜這意味著一些代碼可能會引發(fā)一個不再被處理的異常。我沒有把握。我的代碼的兩個版本都不處理任何異常，因此第一個版本中任何與異常相關(guān)的操作在第二個版本中都應(yīng)該是相同的。
無論如何，第二個版本的代碼是對，是這樣寫它的方法。在第一個版本中，編譯器的錯誤消息是正確的。這個so變量可能未初始化。特別是，如果SomeObject構(gòu)造器失敗，so將不會被初始化，因此嘗試調(diào)用它將是一個錯誤。so.CleanUp..始終輸入try剖面后您已經(jīng)獲得了finally部分最后確定。
這個try-finally塊之后的so初始化只來保護(hù)SomeObject例如，不管發(fā)生什么事情，都要把它清理干凈。如果有其他需要運(yùn)行的東西，但它們與SomeObject實(shí)例被分配了屬性，那么它們應(yīng)該進(jìn)入另一個 try-finally布洛克，可能是我展示的那個。
在使用前需要手動分配變量并不會導(dǎo)致真正的問題。這只會導(dǎo)致一些小麻煩，但是您的代碼會更好。您將擁有范圍更有限的變量，并且try-finally不試圖保護(hù)太多的障礙。
如果局部變量具有默認(rèn)值，則so在第一個例子中null..那根本解決不了任何問題。而不是在finally布洛克，你會有一個NullPointerException潛伏在那里藏無論在代碼的“在這里做一些工作”部分可能發(fā)生什么其他異常。(或在finally節(jié)自動鏈接到以前的異常？我不記得了。即使如此，你也會有一個額外的例外，就像真正的例外。)
