Skip to content

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

Closed
jxblum opened this issue Oct 19, 2023 · 0 comments
Closed
Assignees
Labels
type: task A general task

Comments

@jxblum
Copy link
Contributor

jxblum commented Oct 19, 2023

This task consistently aligns all of Spring Data Redis's catch blocks / Exception handlers with the core Spring Framework's Exception (or Throwable) variable reference names, which is primarily (and nearly consistently)... ex.

Additionally, the core Spring Framework also uses ignore in places where the Exception (or Throwable) is ignored.

NOTE: Unfortunately, only in a couple/three places (or so) did the core Spring Framework use inconsistent Exception variable names, such as exc. However, nearly all are named ex.

Now, in Spring Data Redis, ex and ignore are consistently and appropriately used everywhere. The are only 2 exceptions to this convention:

  1. 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).

  2. In only 1 place (i.e. ScanCursor) was the Exception variable named "nested" due to try-catch block nesting, as in:

try {
    // Exceptional code
} catch (Exception ex) {
    try {
        // More Exceptional code
    } catch (RuntimeException nested) {
        ex.addSuppressed(nested);
    }
}

In a few places, the Exception handler logic in catch blocks were refactored to be more readable, separating Exception message construction/formatting from the instantiation and throwing of the Exception itself.

Finally, String.format(..) was consistently applied to all Exception messages that require formatting.

I used the following REGEX expressions to search and modify our Exception blocks:

catch \(.*Exception e\)
catch \(.*Exception ex\)
catch \(.*Exception expected\)
catch \(.*Exception ignore\)
catch \(.*Exception [^ex|^ignore|^nested].*\)
@jxblum jxblum added the type: task A general task label Oct 19, 2023
@jxblum jxblum added this to the 3.2 GA (2023.1.0) milestone Oct 19, 2023
@jxblum jxblum self-assigned this Oct 19, 2023
@jxblum jxblum changed the title Refine all catch blocks to use consistent naming for Exception references Refine all catch blocks to use consistent naming for Exception variable references Oct 19, 2023
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
@jxblum jxblum changed the title Refine all catch blocks to use consistent naming for Exception variable references Refine all catch blocks to use consistent naming for Exception variables Oct 19, 2023
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
Labels
type: task A general task
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants