Das "Problem", auf das Sie verweisen scheint diese Situation zu beschreiben:
SomeObject so;
try {
// Do some work here ...
so = new SomeObject();
so.DoUsefulThings();
} finally {
so.CleanUp(); // Compiler error here
}
Der Kommentator bemängelt, dass der Compiler die Zeile in der finally Abschnitt und behauptet, dass so könnte nicht initialisiert sein. Der Kommentar erwähnt dann eine andere Art, den Code zu schreiben, wahrscheinlich so etwas wie dies:
// Do some work here ...
SomeObject so = new SomeObject();
try {
so.DoUsefulThings();
} finally {
so.CleanUp();
}
Der Kommentator ist mit dieser Lösung unglücklich, weil der Compiler dann sagt, dass der Code "innerhalb eines Try" stehen muss. Ich vermute, das bedeutet, dass ein Teil des Codes eine Ausnahme auslösen kann, die nicht mehr behandelt wird. Ich bin mir nicht sicher. Keine der beiden Versionen meines Codes behandelt Ausnahmen, also sollte alles, was mit Ausnahmen zu tun hat, in der ersten Version genauso funktionieren wie in der zweiten.
Wie auch immer, diese zweite Version des Codes ist die richtig Art und Weise, es zu schreiben. In der ersten Version war die Fehlermeldung des Compilers korrekt. Die so Variable möglicherweise nicht initialisiert ist. Insbesondere, wenn die SomeObject Konstruktor scheitert, so wird nicht initialisiert, so dass es ein Fehler ist, zu versuchen, die so.CleanUp . Geben Sie immer die try Abschnitt nach Sie haben die Ressource erworben, die die finally Der Abschnitt ist abgeschlossen.
Le site try - finally Block nach dem so Initialisierung ist vorhanden nur zum Schutz der SomeObject Instanz, um sicherzustellen, dass es bereinigt wird, egal was sonst passiert. Wenn es andere Dinge, die laufen müssen, aber sie haben nichts damit zu tun, ob die SomeObject Instanz Eigentum zugewiesen wurde, dann sollten sie in eine andere try - finally Block, wahrscheinlich einen, der den von mir gezeigten umschließt.
Die manuelle Zuweisung von Variablen vor ihrer Verwendung führt nicht zu echten Problemen. Es führt nur zu kleineren Schwierigkeiten, aber Ihr Code wird dadurch besser. Sie werden Variablen mit einem begrenzteren Anwendungsbereich haben, und try - finally Blöcke, die nicht versuchen, zu viel zu schützen.
Wenn lokale Variablen Standardwerte haben, dann so im ersten Beispiel wäre es gewesen null . Das hätte nicht wirklich etwas gelöst. Anstatt einen Kompilierfehler in der finally Block, hätten Sie einen NullPointerException die dort lauern könnten ausblenden welche andere Ausnahme auch immer in dem Abschnitt "Do some work here" des Codes auftreten könnte. (Oder machen Sie Ausnahmen in finally Abschnitte automatisch mit der vorherigen Ausnahme verkettet? Ich weiß es nicht mehr. Selbst wenn, würden Sie eine zusätzliche Ausnahme in den Weg der eigentlichen haben.)
