The problem with this is that the 500 error does not provide any information about the error.
Which for me is a bad thing. Now that I think about it i am seeing some light... I do like the idea of somehow passing a string to it. With cgi, it makes me mad because i have to got and check the logs...(development stage). However, in production i like the idea of apache throwing the 500 instead of a blank page... I guess i am straddling the fence here... On Wed, 2002-11-20 at 16:11, James Cox wrote: > it can; 500 means server error -- perl, cgi, mod_include, etc all do it, so > why shouldn't php? > > -- james > > > -----Original Message----- > > From: John Coggeshall [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, November 20, 2002 11:06 PM > > To: 'James Cox' > > Cc: 'PHP Developers Mailing List' > > Subject: RE: [PHP-DEV] error handling > > > > > > > > >true... > > > > > >i'd like to see a 500 error though, and some persistent vars... > > > > See, the problem that I'm seeing here is that I don't believe PHP is > > reponsible for setting the error code returned by PHP.. For instance, a > > 404 error isn't handle by PHP at all. Likewise, I don't think PHP can > > say "turn this into a 500 error" to Apache. > > > > John > > > > > > > > > > -- james > > > > > >> -----Original Message----- > > >> From: John Coggeshall [mailto:[EMAIL PROTECTED]] > > >> Sent: Wednesday, November 20, 2002 10:48 PM > > >> To: 'James Cox' > > >> Subject: RE: [PHP-DEV] error handling > > >> > > >> > > >> >that can't really be done because parsing has happened, and so > > >> >output has started -- but if we return status 500, the > > >> >webserver can manage it properly.. > > >> > > >> Only if output buffering is off. Custom error handling should have > > >> output buffering on anyway as I've already said... John > > >> > > >> > > > > > > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
