-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Refine all catch
blocks to use consistent naming for Exception
variables
#2748
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
catch
blocks to use consistent naming for Exception
referencescatch
blocks to use consistent naming for Exception
variable references
jxblum
added a commit
to jxblum/spring-data-redis
that referenced
this issue
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 spring-projects#2748
catch
blocks to use consistent naming for Exception
variable referencescatch
blocks to use consistent naming for Exception
variables
jxblum
added a commit
that referenced
this issue
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
jxblum
added a commit
to jxblum/spring-data-redis
that referenced
this issue
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 spring-projects#2748
mp911de
pushed a commit
that referenced
this issue
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This task consistently aligns all of Spring Data Redis's
catch
blocks /Exception
handlers with the core Spring Framework'sException
(orThrowable
) variable reference names, which is primarily (and nearly consistently)...ex
.Additionally, the core Spring Framework also uses
ignore
in places where theException
(orThrowable
) is ignored.Now, in Spring Data Redis,
ex
andignore
are consistently and appropriately used everywhere. The are only 2 exceptions to this convention:If the Exception handler is in a TEST class and "expected" , but not referenced or used in any way, then the "
expected
" keyword was used (only in TESTS).In only 1 place (i.e.
ScanCursor
) was theException
variable named "nested
" due totry-catch
block nesting, as in:In a few places, the Exception handler logic in
catch
blocks were refactored to be more readable, separatingException
message construction/formatting from the instantiation and throwing of theException
itself.Finally,
String.format(..)
was consistently applied to allException
messages that require formatting.I used the following REGEX expressions to search and modify our
Exception
blocks:The text was updated successfully, but these errors were encountered: