<?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>Fri, 24 May 2013 04:41:01 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[PHPBuilder.com: Four Sane Solutions for PHP Debugging]]></title>
      <guid>http://www.phpdeveloper.org/news/15388</guid>
      <link>http://www.phpdeveloper.org/news/15388</link>
      <description><![CDATA[<p>
On PHPBuilder.com today there's a new article from <i>Jason Gilmore</i> sharing what he calls "four sane solutions" to help you debug your PHP applications better than just an <a href="http://php.net/echo">echo</a> or <a href="http://php.net/var_dump">var_dump</a>.
</p>
<blockquote>
Few tasks are more tedious and frustrating than debugging a Web application. [...] Fortunately, PHP developers have a number of powerful debugging solutions at their disposal. Whether you're merely inspecting array contents or attempting to determine the status of an Ajax-driven POST response, these four solutions are guaranteed to have an immediate impact on your productivity.
</blockquote>
<p>
His four solutions involve changing the error reporting level on your development environment higher than production to catch issues that might slip through unnoticed, using <a href="http://xdebug.org">XDebug</a>, integrating <a href="http://www.firephp.org/">FirePHP</a> and using <a href="http://www.webopedia.com/TERM/T/test_driven_development.html">test-driven development</a> to be sure things work from the outset.
</p>]]></description>
      <pubDate>Fri, 05 Nov 2010 08:41:28 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Brian Moon's Blog: The death of die()]]></title>
      <guid>http://www.phpdeveloper.org/news/12365</guid>
      <link>http://www.phpdeveloper.org/news/12365</link>
      <description><![CDATA[<p>
<i>Brian Moon</i> has <a href="http://brian.moonspot.net/dont-use-the-die-function">called for the death of die()</a>:
</p>
<blockquote>
Now, I have no actual authority to do so.  My PHP CVS karma does not extend that far.  And I doubt it will actually get removed despite it being nothing more than an alias for exit now. No, what I would like to call a death to is the usage of die such as [echoing out a message to the user instead of doing proper error handling].
</blockquote>
<p>
He points out a few perfectly viable alternatives like the <a href="http://www.php.net/exceptions">exception handlers</a>, the <a href="http://www.php.net/trigger_error">trigger_error</a> function and custom <a href="http://www.php.net/set_error_handler">error handlers</a>.
</p>]]></description>
      <pubDate>Fri, 17 Apr 2009 12:02:29 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Douglas Brown's Blog: Quick Methods Used for Solving PHP Errors]]></title>
      <guid>http://www.phpdeveloper.org/news/11637</guid>
      <link>http://www.phpdeveloper.org/news/11637</link>
      <description><![CDATA[<p>
<i>Douglas Brown</i> has <a href="http://www.brownphp.com/2008/12/quick-methods-used-for-solving-php-errors/">posted some hints</a> to help you find errors in your PHP scripts all centered around error reporting settings.
</p>
<blockquote>
There are several methods to solve errors in PHP code. Sometimes when the user waits to see an output a blank page will be shown if there is an error. To show the errors E_ALL^E_STRICT is used for the PHP 5 version. Contrarily, remaining versions just use E_ALL.
</blockquote>
<p>
He talks about the log_errors and display_errors settings in your php.ini, the <a href="http://php.net/error_reporting">error_reporting</a> function call or a custom error handler as shown <a href="http://us2.php.net/manual/en/function.error-reporting.php#73759">in this example</a> from the PHP manual.
</p>]]></description>
      <pubDate>Tue, 30 Dec 2008 07:57:21 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[Cyberlot's Blog: PHP bugs, whos responsible? Do they even read them?]]></title>
      <guid>http://www.phpdeveloper.org/news/7170</guid>
      <link>http://www.phpdeveloper.org/news/7170</link>
      <description><![CDATA[<p>
In <a href="http://www.cyberlot.net/php-bugs-whos-responsible-do-they-even-read-them">this new post</a> to his blog, <i>Richard Thomas</i> talks about a bug issue that he's "gotten in the middle of" and the conflict between the PHP group and the PEAR developers that came out of it.
</p>
<blockquote>
Today I managed to get right in the <a href="http://pear.php.net/bugs/bug.php?id=9950">middle of this</a>. [...] Both pear and php are pointing the fingers at each other, neither seem to be able to work together and Im not even sure if either one of them has even taken the time to run my test code and realize what the issue is to begin with.
</blockquote>
<p>
The problem comes when he created a a script with the Pear Mail, Mail_mime and Net_SMTP PEAR classes and, following the execution of the rest of the script, tried it both ways - turning the erro reporting back off or not messing with it at all. As a result, the code with the ending error_reporting() call throws an error, the one without does not.
</p>
<p>
Unfortunately, at the time of <a href="http://www.cyberlot.net/php-bugs-whos-responsible-do-they-even-read-them">this writing</a> both sides are still pointing at the other for blame on the issue.
</p>]]></description>
      <pubDate>Fri, 26 Jan 2007 10:43:00 -0600</pubDate>
    </item>
  </channel>
</rss>
