Apply consistent Exception variable names to all catch blocks
#2749
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jxblum
changed the title
Exception variable names to all catch blocks
We now consistently align with the core Spring Framework's use of 'ex' as the variable name for Exceptions handled in catch blocks, and 'ignore' for all Exceptions thrown, but ignored by framework code. Both 'ex' and 'ignore' were appropriately used based on the context and nautre of the Exception handler in the catch block. Additionally, we use the 'expected' variable name for Exception thrown in tests where the thrown Exception is the expected outcome of the test case. Only 1 exception exists to these name conventions, and that is 'nested', which was necessarily used in ScanCursor due to the nested try-catch blocks. Applied consistent use of String.format(..) to Exception messages requiring formatting. Formatted catch block according to source code formatting style. Closes #2748
jxblum
changed the title
Exception variable names to all catch blocksException variable names to all catch blocks
mp911de
reviewed
Oct 19, 2023
| @@ -123,8 +123,8 @@ public JedisClusterConnection(JedisCluster cluster) { | |||
| Object custerCommandExecutor = executorDfa.getPropertyValue("executor"); | |||
| DirectFieldAccessor dfa = new DirectFieldAccessor(custerCommandExecutor); | |||
| clusterCommandExecutor.setMaxRedirects((Integer) dfa.getPropertyValue("maxRedirects")); | |||
| } catch (Exception e) { | |||
| // ignore it and work with the executor default | |||
| } catch (Exception ignore) { | |||
|
Looks pretty decent, thank you. It makes sense to backport the changes into 3.1.x as well so we simplify future backports. |
mp911de
pushed a commit
that referenced
this pull request
Oct 19, 2023
We now consistently align with the core Spring Framework's use of 'ex' as the variable name for Exceptions handled in catch blocks, and 'ignore' for all Exceptions thrown, but ignored by framework code. Both 'ex' and 'ignore' were appropriately used based on the context and nautre of the Exception handler in the catch block. Additionally, we use the 'expected' variable name for Exception thrown in tests where the thrown Exception is the expected outcome of the test case. Only 1 exception exists to these name conventions, and that is 'nested', which was necessarily used in ScanCursor due to the nested try-catch blocks. Applied consistent use of String.format(..) to Exception messages requiring formatting. Formatted catch block according to source code formatting style. Closes #2748 Original pull request: #2749
mp911de
pushed a commit
that referenced
this pull request
Oct 19, 2023
We now consistently align with the core Spring Framework's use of 'ex' as the variable name for Exceptions handled in catch blocks, and 'ignore' for all Exceptions thrown, but ignored by framework code. Both 'ex' and 'ignore' were appropriately used based on the context and nautre of the Exception handler in the catch block. Additionally, we use the 'expected' variable name for Exception thrown in tests where the thrown Exception is the expected outcome of the test case. Only 1 exception exists to these name conventions, and that is 'nested', which was necessarily used in ScanCursor due to the nested try-catch blocks. Applied consistent use of String.format(..) to Exception messages requiring formatting. Formatted catch block according to source code formatting style. Closes #2748 Original pull request: #2749
|
Thank you for your contribution. That's merged and backported now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See #2748.
It should also be NOTED that, in certain
catch (InterruptedException ex)blocks, theexException variable was not used or referenced. However, that does NOT mean the Exception handler did not "handle" theInterruptedException!The simple invocation of
Thread.currentThread().interrupt()IS an act of handling theInterruptedExceptionand does have downstream consequences (or in other words, "side effects"). Therefore, the Exception variable nameexwas deliberately kept in these cases.