Empty Finally Block¶
What does this mean ?¶
An empty finally adds no cleanup. It may be leftover code or a sign that intended cleanup was omitted. Its presence alone does not prove a leak: a helper such as File.ReadAllText manages its own file handle, for example.
What can happen ?¶
If the surrounding code owns a resource and never releases it, repeated calls can exhaust that resource. If no cleanup is required, the empty block mainly obscures intent. Adding an arbitrary function call does not correct ownership.
Recommendation¶
Identify who owns each resource. Remove redundant empty blocks, or implement the actual required cleanup using using, await using or the API's documented lifecycle. Cleanup paths should not replace the original error with avoidable new errors. finally is not guaranteed to run after every possible process termination.
Sample Code¶
// Incorrect: the owned stream is never disposed.
var stream = File.OpenRead(path);
try { return stream.ReadByte(); }
finally { }
// Correct for a method returning int; disposal occurs when leaving the scope.
using var stream = File.OpenRead(path);
return stream.ReadByte();
The path is assumed to be authorized application input; resource cleanup does not prevent path traversal.
Regression checks¶
With a fixture resource, verify cleanup on both success and exceptions. Confirm that removing an empty block preserves the intended behavior when no resource is owned. Avoid tests that depend on platform-specific file locking alone.