<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Wed, 19 Jun 2013 18:38:03 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Jonnay's Blog: An issue with PHP's error handling]]></title>
      <guid>http://www.phpdeveloper.org/news/4692</guid>
      <link>http://www.phpdeveloper.org/news/4692</link>
      <description><![CDATA[On <i>Jonnay</i>'s blog today (at jonnay.net), there's <a href="http://blog.jonnay.net/archives/593-An-issue-with-PHPs-error-handling.html">this new post</a> talking about an issue with the way PHP handles certain errors.
<p>
<quote>
<i>
With all my REST and AJAX explorations, I have run into what I consider to be a fundamental issue in PHP's error handling: when the parser or interpreter runs into an error it will always return HTTP status code 200.
<p>
Semantically this is wrong. Here is the way it should be, at least in my eyes:
<p>
If PHP runs into a non-recoverable error (E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR and E_COMPILE_WARNING; i.e. where the error cannot be trapped by set_error_handler()), it should spit out a HTTP status code of 500 (Internal Server Error), and depending on the setting of the ini directive display_errors display the error text, or conversely the standard Internal Server Error page.
</i>
</quote>
<p>
He <a href="http://blog.jonnay.net/archives/593-An-issue-with-PHPs-error-handling.html>metntions</a> that he'll have to code around it in his next version of <a href="http://wiki.jonnay.net/bunny/meditation/meditation">meditation</a> (a set of classes that aid in REST APIs).]]></description>
      <pubDate>Thu, 19 Jan 2006 07:35:42 -0600</pubDate>
    </item>
  </channel>
</rss>
