title: Java Style: Properly handling exceptions
body: <p>I keep getting stuck conceptually on deciding an Exception-handling structure for my project.</p>
  
  <p>Suppose you have, as an example:</p>
  
  <pre><code>public abstract class Data {
     public abstract String read();
  }
  </code></pre>
  
  <p>And two subclasses FileData, which reads your data from some specified file, and StaticData, which just returns some pre-defined constant data.</p>
  
  <p>Now, upon reading the file, an IOException may be thrown in FileData, but StaticData will never throw.  Most style guides recommend propagating an Exception up the call stack until a sufficient amount of context is available to effectively deal with it.</p>
  
  <p>But I don't really want to add a throws clause to the abstract read() method.  Why?  Because Data and the complicated machinery using it knows nothing about files, it just knows about Data.  Moreover, there may be other Data subclasses (and more of them) that never throw exceptions and deliver data flawlessly.</p>
  
  <p>On the other hand, the IOException is necessary, for if the disk is unreadable (or some such) an error <em>must</em> be thrown.  So the only way out that I see is catching the IOException and throwing some RuntimeException in its place.</p>
  
  <p>Is this the correct philosophy?</p>