It would still be good to have as there are tons of sites that use sessions and plain header() calls - they care of not having the output before processing is done.
If E_PARSE error happens after an output the header() can fail bad too with headers sent message. But, if one wants to control well the whole error thing - it would then be possible. -- Maxim Maletsky [EMAIL PROTECTED] Kjartan Mannes <[EMAIL PROTECTED]> wrote... : > Monday, November 18, 2002, 11:43:48 AM, John Coggeshall wrote: > > Back on the note that I was discussing (the E_PARSE with a user > > error-handler), Perhaps the issue can be slightly skirted without having > > to code a whole lot... Specifically, what about simply re-directing the > > user to another URL in the event of a fatal PHP error (as specified by a > > directive)... Ie. > > > On_fatal_error=http://somewhere.com/error.php > > > Where on a E_PARSE, or something similar, PHP basically does a C-version > > of: > > > <?php header("Location: http://somewhere.com/error.php?errno=4";); ?> > > > This way, users who don't care can still re-direct a browser to a nice > > and pretty "sorry, the server is really screwed" HTML page... Or, if > > they'd like, they can simply take that error number and create a > > error-handler in PHP without us having to bother with the problems > > surrounding a bad parser-state... > > I don't think this will work. First of all PHP would have to do output > buffering as sending an header() after output has been sent wont work. > > <? > print "Welcome"; > include("File that doesn't parse.inc"); > ?> > > This would show the parse error then a header() error, unless you buffer > everything and only do output after processing. > > Also if I allow users to input PHP code to allow for greater > customization of an application then I wouldn't want eval() to redirect > you to the page saying the site is down for maintenance when they > preview their script. (I'd rather have eval() create a non fatal error > so I can give them a more useful error message.) > > If people are updating a site with code they haven't tested then you > probably are not running a major site, or shouldn't be. If you expect > things to break while doing an upgrade it is easy enough to force the > web server to serve an "Upgrade in progress page." > > -- > Kjartan <[EMAIL PROTECTED]> (http://natrak.net/) > :: "Choose your friends by their character and your socks by > their color. Choosing your socks by their character makes > no sense, and choosing your friends by their color is > unthinkable." > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
