RE: [PHP-DEV] error handling
| From: | Derick Rethans | Date: | Mon, 18 Nov 2002 13:02:36 +0000 |
| Subject: | RE: [PHP-DEV] error handling | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-91261@lists.php.net to get a copy of this message | ||
On Mon, 18 Nov 2002, John Coggeshall wrote:
> >> Can't argue with that, however (;)), I find it annoying that PHP stops
> >> processing if there is a parse error passed to an eval() command. I'd
> >> like a way to make eval() just return E_PARSE if the script passed to
> >> it fails.
>
> This is exactly the type of situation where E_PARSE really bothers me as
> well.. Although no one likes eval(), and it seems to me it is become
uhm, John, we dont have a E_PARSE yet.
> 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 stil see not why you would want to handle PARSE errors gracefully. If
a user has broken code it should not even be on a production box. Bad
code -> dead site.
Derick
--
---------------------------------------------------------------------------
Derick Rethans http://derickrethans.nl/
JDI Media Solutions
--------------[ if you hold a unix shell to your ear, do you hear the c? ]-