[MINOR] refactor: Calling lock() method outside try block to avoid unnecessary errors

[rickyma]

What changes were proposed in this pull request?

Calling lock() method outside try block to avoid unnecessary errors

Why are the changes needed?

In general, the lock() method should be placed outside the try block. The reason is that if the lock() method throws an exception, it indicates that the lock was not acquired, so there is no need to attempt to release it in the finally block. If the lock() method is placed within the try block and it throws an exception, the finally block will still be executed and attempt to release a lock that was never acquired, leading to errors.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

Existing UTs.

[github-actions]

Test Results

 2 340 files  ±0   2 340 suites  ±0   4h 32m 8s ⏱️ -48s
   908 tests ±0     907 ✅ ±0   1 💤 ±0  0 ❌ ±0 
10 541 runs  ±0  10 527 ✅ ±0  14 💤 ±0  0 ❌ ±0 

Results for commit dbd6b83. ± Comparison against base commit f3775a1.

[jerqi]

@zuston Rust CI still is unstable.

[jerqi]

Is it a best practice for the lock? Any other projects follow the rule?

[rickyma]

Is it a best practice for the lock? Any other projects follow the rule?

The Java documentation, however, leaves lock() outside the try block in the ReentrantLock example. The reason for this is that an unchecked exception in lock() should not lead to unlock() incorrectly being called.

You can refer to Java Doc.

It is described in:
https://stackoverflow.com/a/10868476.

[jerqi]

LGTM, thanks @rickyma