Description
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 asexc
. However, nearly all are namedex
.
Now, in Spring Data Redis, ex
and ignore
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:
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].*\)