title: "Don't catch generic Exceptions!" But how to unravel them?
body: <p>Most of the static code analysis tools suggest not to catch generic (in particular unchecked) exceptions like RuntimeExceptions and Errors.</p>
  
  <p>Unless this Exception barrier might be reasonable at a top level, generally it isn't at a lower level.
  Unfortunately this can be very difficult to achive when rewriting/fixing already existing code, because the underlying possibilities of possible Errors and RuntimeExceptions can be exorbitant.
  Moreover, it is mostly a really time consuming and complex task to dig into the lower code levels to gain some ideas of Exceptions reasonable enough to catch instead of the generic catch.</p>
  
  <p>Do you know any tools or best practices to unravel such generic (unchecked) exceptions into more specific ones?</p>
  
  <p>say we have something like that:</p>
  
  <pre><code>try
  {
      somethingReallyComplex();
  }
  catch (RuntimeException | Error ex)
  {
      Logger.error(this, ex.getClass().getName() + " while doing something really complex", ex)
  }
  </code></pre>
  
  <p>The try block can contain a really complex matter of code with a variety of different RuntimeExceptions and Errors which <strong>make sense</strong> to catch.
  But how can I analyse this code most effectively to unravel the RuntimeException into NullPointerException, ArrayIndexOutOfBoundException... whatever might be reasonable?</p>
  
  <p>Are there any tools that can analyze such code and give suggestions about most common RuntimeExceptions in there and the like?</p>
  
  <p>How do you start to solve this problem?</p>
  
  <p>Where is the subjective or objective "threshold" to say: 
  "No, I just leave it as RuntimeException and add a suppress annotation?"</p>