text: Title: Re-evaluate catch-all exception handling throughout the codebase
  Body: **Summary**
  In the same category as #9679 
  
  During the work of converting from using FindBugs to SpotBugs (#10407) I found that there was a particular class of bugs that we had strewn throughout our codebase - the `REC_CATCH_EXCEPTION`. The bug code, by definition states 
  
  >  REC: Exception is caught when Exception is not thrown (REC_CATCH_EXCEPTION)
  
  > This method uses a try-catch block that catches Exception objects, but Exception is not thrown within the try block, and RuntimeException is not explicitly caught. It is a common bug pattern to say try { ... } catch (Exception e) { something } as a shorthand for catching a number of types of exception each of whose catch blocks is identical, but this construct also accidentally catches RuntimeException as well, masking potential bugs.
  
  > A better approach is to either explicitly catch the specific exceptions that are thrown, or to explicitly catch RuntimeException exception, rethrow it, and then catch all non-Runtime Exceptions, as shown below:
  
  ```java
  try {
      ...
  } catch (RuntimeException e) {
      throw e;
  } catch (Exception e) {
      ... deal with all non-runtime exceptions ...
  }
  ```
  
  To summarize, essentially what I saw is that there are many places throughout our codebase where we `catch(Exception e)` where `Exception` is never thrown. It's essentially a catch-all. However, most situations we either don't want this, or might want to handle the class of `RuntimeException` differently.
  
  
  To rememdy this we should:
  
  - Remove the `REC_CATCH_EXCEPTION` from the spotbugs exclusion list
  - For each instance, carefully evaluate how we want to handle the exceptions and either make a class-wide exception for spotbugs, OR improve the error handling to split between `RuntimeException` and other `Exception` 
  
  
  **Urgency**
  I would estimate this to be middle-to-low priority.
  