title: Why is SQLException a checked exception
body: <p>Can anyone think of a rational reason why <a href="http://docs.oracle.com/javase/6/docs/api/java/sql/SQLException.html" rel="noreferrer"><code>SQLException</code></a> is a <em>checked</em> exception?</p>
  
  <p>Yes, there could be a syntax error in the query<br>
  Yes, the connection might have died<br>
  Yes, there might be a permission problem<br>
  Etc, etc blah blah blah</p>
  
  <p>But practically 100% of the time (once you're running in production), there isn't any problem. </p>
  
  <p>If there is a problem, the calling code can't do anything to recover, so for that reason it should be <em>unchecked</em>.</p>
  
  <p>Being checked create masses of perfunctory <code>try catch</code> blocks throughout the code, as anyone who has been involved with a project that uses JDBC will attest. The code clutter is significant.</p>
  
  <p>Because of the esoteric nature of SQL, the myriad of reasons you may get an SQLException and their complexity means you basically can not recover, unless the exception is caused by temporary network problem, but even then in a synchronous call, you're sunk anyway because you can't wait indefinitely for the network problem to be resolved, so you're going to have to fail the transaction.</p>
  
  <p>Typically, calling SQL looks like this:</p>
  
  <pre><code>try {
      // make some SQL call(s)
  } catch {SQLException e) { 
      // log the exception
      return; // and give up
  }
  </code></pre>
  
  <p>Such code <strong>adds no value</strong>. There nothing reasonable you can do to recover. You might as well let a runtime exception bubble up - ie SQLException should be a <em>runtime</em> (unchecked) exception. </p>