title: Converting errors to exceptions: design flaw?
body: <p>I came across some code recently that used a custom error handler to turn any PHP errors into an generalized application exception. A custom exception handler was also defined that would log the exception if it was within a particular error code range. Example:</p>
  
  <pre><code>class AppException extends Exception
  {
  
  }
  
  function error_handler($errno, $errstr, $errfile, $errline)
  {
      throw new AppException($errstr, $errno);
  }
  
  function exception_handler($exception)
  {
      $min = ...;
      $max = ...;
  
      if ($exception-&gt;getCode() &gt;= $min &amp;&amp; $exception-&gt;getCode() &lt;= $max)
      {
          // log exception
      }
  }
  
  set_error_handler('error_handler');
  set_exception_handler('exception_handler');
  
  $a[1]; // throws exception
  </code></pre>
  
  <p>The problem is that I saw things like:</p>
  
  <pre><code>try
  {
      do_something();
  }
  catch (AppException $exception)
  {
  }
  </code></pre>
  
  <p>Which implies that there is no distinction between actual programming errors and "Exceptional" behavior. Upon further digging, I came across parts of the code that were designed around the idea that PHP errors represented "Exceptional" behavior such as:</p>
  
  <pre><code>...
  
  function my_function($param1, $param2)
  {
      // do something great
  }
  
  try
  {
      my_function('only_one_param');
  }
  catch (AppException $exception)
  {
  }
  </code></pre>
  
  <p>Which ends up obfuscating errors and the design of the application's interface.</p>
  
  <p>What is your opinion on handling errors this way? Is it worth turning PHP's native errors into exceptions? What do you do in situations like the above where a codebase is designed around this idea? </p>