[PHP-DEV] Error handling (no redirect)
Hi, having ported a site from ColdFusion to PHP in a very short time frame, I can safely say, ColdFusion is an overpriced templating system and not a scripting language. There is one convenience however, and that is that any error can be handled by the end user. I found it very inconvenient that parse errors can't be handled, but after a little talk with Derick, he came up with the 'tokenizer' extension. If you can tokenize it, it doesn't contain parse errors. So that's one thing. That still leaves some fatal errors, for which you cannot register an error handler. The general thought on php-dev seems to be, that you shouldn't commit files containing errors into production. This assumes, that php is only used in environments where staging servers and/or people understanding CVS is common. Most hosting environments don't provide these services and even in a controlled environment, it is not always possible to force this infrastructure into the business. Even if this is not a good argument: what's the reason for not handing fatal errors to an error handler? Or maybe it should be looked at better, which errors are considered fatal? I for one, don't understand, why a call to an undefined function, shouldn't be handled by an error handler, unless the undefined function is the error handler. Since an error handler, can only be registered when zend_is_callable returns true, and undefined functions are resolved in 'execute', via zend_hash_find, I can't see any conflict arrising. So - 2 questions here: What was the original reasoning, not to allow error handlers to handle fatal errors? Why can't a call to an undefined function, be an E_USER_ERROR (as a temp solution)? With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
On Thursday 21 November 2002 08:04, Derick Rethans wrote: I still think that an included file just should fail hard and I just dont like this kind of obfucsication. I agree with this 100%. It is IMHO a complete waste of time trying to handle parse errors gracefully. Most solutions proposed in this thread are either server specific or would have an impact on normal php operation (would require output buffering, etc.). Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
John Coggeshall wrote: If I hacked on the source a bit and got this redirect-error thing working, would it Be perhaps worthy of a commit? +1 Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Edin Kadribasic wrote: On Thursday 21 November 2002 08:04, Derick Rethans wrote: I still think that an included file just should fail hard and I just dont like this kind of obfucsication. I agree with this 100%. It is IMHO a complete waste of time trying to handle parse errors gracefully. Most solutions proposed in this thread are either server specific or would have an impact on normal php operation (would require output buffering, etc.). And in the real life you sometimes must change things live on the server, in the middle of the night. If you make a mistake then, and we all do, you will go to sleep without realising that the app/web site no longer works properly. I use logwatch for this at the moment, but that is, IMHO, a very, very, clumsy solution. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Derick Rethans [EMAIL PROTECTED] wrote... : On Thu, 21 Nov 2002, John Coggeshall wrote: Again, what about IIS, etc? Who cares? :) It really would be much better if some person who thinks IIS rulez fixes the ISAPI module. If that doesn't work correctly nobody should use it at all. Never used IIS in my entire life, but I would be scared shall PHP start loosing its IIS support letting .NET and Java more space on Win32 systems. I am sure there are cases when IIS is prefered to Apache on MS servers and when MS is prefered for certain production architectures and these architectures are prefer by certain brains. Don't ask me why - I hate that myself, but we should not ignore if want to be competitive. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Hello PHP-Developers I have an idea! I recently went through the pain of creating an ISAPI DLL for IIS and what I found was that IIS was *incredibly* sensitive to things going wrong in the DLL with the result that the IIS process would hang and the whole damn machine would need a reboot on a regular basis. So, I went back to the drawing board for version 2 of my DLL and I designed an architecture whereby the DLL would be the thinnest I could possibly make it, and the guts would be in a separate application server. I accomplished communication between the DLL and the application server via named pipes, which are very fast and efficient on Win NT and above servers. This works fine and I've never had an IIS crash since. Why don't we move PHP into a separate executable. Design a thin ISAPI DLL which purely passes the data which the ISAPI DLL exposes between the IIS process and the PHP process (or process-pool for added reliability). The resulting page is processed in the application server and returned to the ISAPI DLL where it is output. Then if PHP crashes for whatever reason (i.e. database-client library bug), a) it won't take down IIS and b) it can simply be restarted and continue serving requests. A bit like the way it runs on UNIX really with Apache's process-pool architecture. I think this solution will be *way* easier than trying to fix every single bug in PHP so that it is utterly thread-safe and crash-free. It would also scale more nicely because you could run multiple PHP binaries across different machines if you are doing very intensive PHP stuff. I think this might solve the pain of trying to run PHP on IIS in a non-CGI environment with a relatively trivial piece of code. If anyone wants to take this on I can give source code to my DLL and application server to give you a kickstart in the right direction. Additionally if there is a problem with my idea, I'd love to hear from you all. Nick. On Thu, 21 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : On Thu, 21 Nov 2002, John Coggeshall wrote: Again, what about IIS, etc? Who cares? :) It really would be much better if some person who thinks IIS rulez fixes the ISAPI module. If that doesn't work correctly nobody should use it at all. Never used IIS in my entire life, but I would be scared shall PHP start loosing its IIS support letting .NET and Java more space on Win32 systems. I am sure there are cases when IIS is prefered to Apache on MS servers and when MS is prefered for certain production architectures and these architectures are prefer by certain brains. Don't ask me why - I hate that myself, but we should not ignore if want to be competitive. -- Maxim Maletsky [EMAIL PROTECTED] -- 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
Re: [PHP-DEV] error handling
Writing for newbies, I often heard them mentioning one things they liked about PHP (before even trying to use it) - PHP errors are not 500 weird pages made by your browser. Moving fatal errors to HTTP 500 can be somewhat confusing, unless we have a solid way handling ALL errors in some very logical way. In other words - powerful but clear enough to understand and use for neo programmers. +1 to what someone mentioned earlier - PHP is not *only* for web, it is *primarily* for web. Maybe, using HTTP headers for error handling would make this less obvious. just my +.2c -- Maxim Maletsky [EMAIL PROTECTED] James Cox [EMAIL PROTECTED] 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
Moving fatal errors to HTTP 500 can be somewhat confusing, unless we have a solid way handling ALL errors in some very logical way. In other words - powerful but clear enough to understand and use for neo programmers. Check out my patch and tell me what you think. Since this can be turned on/off (default will be off) we'll maintain the current pretty (sorta) errors and it is completely platform-independant +1 to what someone mentioned earlier - PHP is not *only* for web, it is *primarily* for web. Maybe, using HTTP headers for error handling would make this less obvious. Again, check my patch out and let me know what you think. John just my +.2c -- Maxim Maletsky [EMAIL PROTECTED] James Cox [EMAIL PROTECTED] 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
In Real Life [Patent Pending], if you cripple your production site in the middle of the night then go to bed, you won't have to worry about any of this because you'd be unemployed in the morning. I agree with Derick's assessment. I always have the option of turning display errors off (which is the recommendation for production sites) and cranking stuff out to syslog or some file I can monitor. Throwing a 500 document is ugly, and so 90's. :) Being competitive does not mean 'being like the other guys', a path PHP has carefully and rightfully avoided. Regards Mike Robinson Ivan Ristic writes: Edin Kadribasic wrote: On Thursday 21 November 2002 08:04, Derick Rethans wrote: I still think that an included file just should fail hard and I just dont like this kind of obfucsication. I agree with this 100%. It is IMHO a complete waste of time trying to handle parse errors gracefully. Most solutions proposed in this thread are either server specific or would have an impact on normal php operation (would require output buffering, etc.). And in the real life you sometimes must change things live on the server, in the middle of the night. If you make a mistake then, and we all do, you will go to sleep without realising that the app/web site no longer works properly. I use logwatch for this at the moment, but that is, IMHO, a very, very, clumsy solution. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Mike Robinson wrote: In Real Life [Patent Pending], if you cripple your production site in the middle of the night then go to bed, you won't have to worry about any of this because you'd be unemployed in the morning. I assume then that you run regression tests for your web sites after every change? Or stay awake throughout the night? Or not make mistakes at all and so you have nothing to fix at nights? :)) Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
On Thu, 21 Nov 2002, Ivan Ristic wrote: Mike Robinson wrote: In Real Life [Patent Pending], if you cripple your production site in the middle of the night then go to bed, you won't have to worry about any of this because you'd be unemployed in the morning. I assume then that you run regression tests for your web sites after every change? Or stay awake throughout the night? Or not make mistakes at all and so you have nothing to fix at nights? We were talking about parse errors here. php -l before you put it life should be enough for that. And yes, I run that before 'cvs commit'. Also, I sleep at night and do not dream about coding or website errors at all. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
We were talking about parse errors here. php -l before you put it life should be enough for that. And yes, I run that before 'cvs commit'. Well, I am afraid that it is not that simple, as there are other fatal errors that cannot be caught and where lint is useless. For example, $object-wrong_function_name() is a fatal error. Since I am no perfect and make mistakes all the time, I would like my programming environment of choice to help me as much as possible. Also, from a management point of view (I manage programmers), what you are describing there can work in some cases but what if a programmer forgets/is-too-lazy to to that? I don't want to wait for the next morning to know about it. Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
The point is that it should be possible to throw a HTTP 500 error. This is really only useful in production environments, ie, when the code going live should already be free of things like parse errors. Throwing a 500 error would make it easier to merge into your already existing error handling systems -- eg, for 404. -- james -Original Message- From: Maxim Maletsky [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 12:15 PM To: James Cox Cc: [EMAIL PROTECTED]; 'PHP Developers Mailing List' Subject: Re: [PHP-DEV] error handling Writing for newbies, I often heard them mentioning one things they liked about PHP (before even trying to use it) - PHP errors are not 500 weird pages made by your browser. Moving fatal errors to HTTP 500 can be somewhat confusing, unless we have a solid way handling ALL errors in some very logical way. In other words - powerful but clear enough to understand and use for neo programmers. +1 to what someone mentioned earlier - PHP is not *only* for web, it is *primarily* for web. Maybe, using HTTP headers for error handling would make this less obvious. just my +.2c -- Maxim Maletsky [EMAIL PROTECTED] James Cox [EMAIL PROTECTED] 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 -- 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
RE: [PHP-DEV] error handling
In Real Life [Patent Pending], if you cripple your production site in the middle of the night then go to bed, you won't have to worry about any of this because you'd be unemployed in the morning. +1... don't commit code without QA! I agree with Derick's assessment. I always have the option of turning display errors off (which is the recommendation for production sites) and cranking stuff out to syslog or some file I can monitor. Throwing a 500 document is ugly, and so 90's. :) Being competitive does not mean 'being like the other guys', a path PHP has carefully and rightfully avoided. i see your point, but php doesn't really provide a way of halting on all errors, unless you code yourself a funky error handler and well... it gets messy. throwing http 500 is the right way to do it (tm), and i think would be better http conformance if we did. -- james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
Also, from a management point of view (I manage programmers), what you are describing there can work in some cases but what if a programmer forgets/is-too-lazy to to that? I don't want to wait for the next morning to know about it. if a programmer is too lazy to test, fire them. there are plenty more better ones to hire. -- james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
James Cox wrote: Also, from a management point of view (I manage programmers), what you are describing there can work in some cases but what if a programmer forgets/is-too-lazy to to that? I don't want to wait for the next morning to know about it. if a programmer is too lazy to test, fire them. there are plenty more better ones to hire. That's very funny! :) You are oversimplifying a complex issue. Real life is a series of compromises. But let us not stray anymore, this is not the subject of the discussion. If you want, you can still email me privately. Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
John Coggeshall wrote: |I know this is possible now, but not within the error handling |function of PHP, or without setting a custom error handler. Well, it's not really possible now -- a E_PARSE won't get thrown to a custom PHP handler, it'll just die with a parse error. It is possible. Not pretty but still possible :) You can use a series of hacks to make PHP behave and allow you to intercept an fatal error, and extract the error message. In short: * You use auto_append to append a short PHP file that only sets a flag to true * You install a custom error handle to handle normal errors. * You need to turn the output buffering on. * You register a shutdown function the checks the flag; if the flag is set to false - you have a fatal error on your hands. In that case you need to clear the output buffer but not before you extract the fatal error message (you need to have display_errors set to on). Then you can forward the fatal error to your normal error handler for processing. The full explanation is available here: http://www.webkreator.com/php/configuration/foolproof-php-handling-2.html I do not recall the version I used and I haven't checked whether this still works with recent releases. It did work at the time. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Create a configuration directive error_handler which accepts one of Two values... Either a PHP script (like auto_prepend) which is And how about that we change PHP so that it changes the status of the response to 500 on a fatal error? Then you would be able to use the Apache directive ErrorDocument 500 /handle-my-errors.php to deal with them. You would have to use output buffering, of course, but using output buffering is the only way to shield your users from errors anyway. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
On Wed, 20 Nov 2002, Ivan Ristic wrote: Create a configuration directive error_handler which accepts one of Two values... Either a PHP script (like auto_prepend) which is And how about that we change PHP so that it changes the status of the response to 500 on a fatal error? Then you would be able to use the Apache directive ErrorDocument 500 /handle-my-errors.php to deal with them. You would have to use output buffering, of course, but using output buffering is the only way to shield your users from errors anyway. +1 !! Why didn't anyone think of this before? :) - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
|And how about that we change PHP so that it changes |the status of the response to 500 on a fatal error? Then |you would be able to use the Apache directive | |ErrorDocument 500 /handle-my-errors.php | |to deal with them. You would have to use output buffering, |of course, but using output buffering is the only way to |shield your users from errors anyway. | |+1 !! | |Why didn't anyone think of this before? :) A couple of problems with that: 1) No way for handle-my-errors.php to know the details of the error such as errorcode, file, etc) 2) Relies on the web server (not PHP) to re-direct the user to another script If we are willing to do this, think we're better off creating a directive error_url which requires output buffering enabled and re-directs the user to another URL with GET parameters containing the error messages. John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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
RE: [PHP-DEV] error handling
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
RE: [PHP-DEV] error handling
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
RE: [PHP-DEV] error handling
a combination of log_error directives and a 500 error you can handle would do the trick... we're talking about production... have a script to check your php log and mail / sms you if it gets full.. -- james -Original Message- From: Ray Hunter [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 11:17 PM To: James Cox Cc: 'PHP Developers Mailing List' Subject: RE: [PHP-DEV] error handling 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
Re: [PHP-DEV] error handling
The problem with this is that the 500 error does not provide any information about the error. To the user, no. I wouldn't want users to see low level error messages anyway. Since standard error handlers can catch normal messages, the fact that a 500 error has occured means that something bigger is wrong and you have to go and fix it anyway. Then you can look the error message in the log file and see what the problem was. Also, the message will probably be parse error at line XXX anyway :)) You would probably keep this off during the development phase, in which case messages will appear directly on screen. Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
I also believe that header(HTTP/1.1 500 ...) will do the trick, and there is also the revamped Apache hooks stuff that is being worked on that should give even more control to developers who choose to use it. For some reason here, everyone is forgetting that PHP isn't running just on apache web servers. I don't agree with the idea of relying on the potential of apache_hooks, when they are still experimental and furthermore of course Apache-specific. I think everyone is in agreement here that better ways to deal with fatal errors is desirable, and we seem to be aruging about implementation. Although I do like the idea of having a 500 error, I don't believe it provides enough flexablity to the developer when dealing with the error (since there is no way to determine the nature of the error). With that in mind, here's what I propose: 1) two new configuration directives. The first error_handler which supports the following forms: internal (default) -- the standard method of handling errors url Upon an error, re-direct the browser to a new URL and pass a GET query containing the error info servercreate a 500 error The second directive error_handler_url should specify the URL to pass to if 'url' for error_handler is specififed 2) If the URL option is used, all of the standard error parameters are passed via GET parameters I believe this way provides the most flexablity to deal with any error PHP is going to throw at a user without breaking old code. Please RFC of course :) John -Original Message- From: Chris Shiflett [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 6:31 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [PHP-DEV] error handling --- John Coggeshall [EMAIL PROTECTED] wrote: 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. Chris -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
On Wed, 20 Nov 2002, John Coggeshall wrote: |And how about that we change PHP so that it changes |the status of the response to 500 on a fatal error? Then |you would be able to use the Apache directive | |ErrorDocument 500 /handle-my-errors.php | |to deal with them. You would have to use output buffering, |of course, but using output buffering is the only way to |shield your users from errors anyway. | |+1 !! | |Why didn't anyone think of this before? :) A couple of problems with that: 1) No way for handle-my-errors.php to know the details of the error such as errorcode, file, etc) 2) Relies on the web server (not PHP) to re-direct the user to another script If we are willing to do this, think we're better off creating a directive error_url which requires output buffering enabled and re-directs the user to another URL with GET parameters containing the error messages. If ErrorDocument is implemented as a sub-request in Apache, it would be enough for PHP to set one or more Apache notes with the necessary information. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
If ErrorDocument is implemented as a sub-request in Apache, it would be enough for PHP to set one or more Apache notes with the necessary information. Again, what about IIS, etc? John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
On Thu, 21 Nov 2002, John Coggeshall wrote: If ErrorDocument is implemented as a sub-request in Apache, it would be enough for PHP to set one or more Apache notes with the necessary information. Again, what about IIS, etc? Who cares? :) It really would be much better if some person who thinks IIS rulez fixes the ISAPI module. If that doesn't work correctly nobody should use it at all. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
Who cares? :) It really would be much better if some person who thinks IIS rulez fixes the ISAPI module. If that doesn't work correctly nobody should use it at all. I'm not saying I'm a IIS fan. :) I rather implement one solution Which works, period. IMHO that's better than have different work arounds for each Version of PHP. If I hacked on the source a bit and got this redirect-error thing working, would it Be perhaps worthy of a commit? John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
On Thu, 21 Nov 2002, John Coggeshall wrote: Who cares? :) It really would be much better if some person who thinks IIS rulez fixes the ISAPI module. If that doesn't work correctly nobody should use it at all. I'm not saying I'm a IIS fan. :) I rather implement one solution Which works, period. IMHO that's better than have different work arounds for each Version of PHP. If I hacked on the source a bit and got this redirect-error thing working, would it be perhaps worthy of a commit? I still think that an included file just should fail hard and I just dont like this kind of obfucsication. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
On Mon, 18 Nov 2002, John Coggeshall wrote: |I know this is possible now, but not within the error handling |function of PHP, or without setting a custom error handler. Well, it's not really possible now -- a E_PARSE won't get thrown to a custom PHP handler, it'll just die with a parse error. And this can never be supported safely, as a parse error leaves the parse in an unstable state. Also, I really don't think that we should try to add hacks to make this possible. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
|And this can never be supported safely, as a parse error leaves the |parse in an unstable state. Also, I really don't think that we should |try to add hacks to make this possible. Is this directed toward my wish (of having a secondary error if the custom error handler also errors) or toward Mattia's suggestion? John |Derick | |-- | |--- | | Derick Rethans |http://derickrethans.nl/ | JDI Media Solutions |--[ |if you hold a unix shell to your ear, do you hear the c? ]- | | -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
On Mon, 18 Nov 2002, John Coggeshall wrote: |And this can never be supported safely, as a parse error leaves the |parse in an unstable state. Also, I really don't think that we should |try to add hacks to make this possible. Is this directed toward my wish (of having a secondary error if the custom error handler also errors) or toward Mattia's suggestion? Both? I'm not totally sure what you mean with when the custom error handler also has errors. Can you elaborate? (and can you please use for quoting mail?) Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Well, I certainly don't want errors handled this way for my web apps. And you would be hard pressed to find 2 people on this list that agree exactly how to do it which is why PHP provides you with the tools to do it any way you want. -Rasmus On Mon, 18 Nov 2002, Mattia wrote: I think in a modern web application the error handling function should do the following: in case of error (any: parse error, internal application error,) 1. a message should be shown to the user sayng that an error has occured like an internal error has occured. the webmaster has been notified via email 2. a more detailed message should be logged in a generic system ErrorLog, or notified via email or fax, or telephone, or SMS. Depending on the severity of the error (warning, fatal,...) All this done with PHP error handling function (this is not to male distinction between PHP error and application internal error), and the ErrorLog kept via system/server methods (like syslogd). The message shown to the user should be accompained by an HTTP 500 (or more) error. This to make clear to human users that an error has occured therefore the request cannot be fulfilled, and if the cliens is another computer (robot,...) to make it as well (computer look at error codes rather than at things written for humans. I know this is possible now, but not within the error handling function of PHP, or without setting a custom error handler. Mattia Cazzola -- 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
RE: [PHP-DEV] error handling
Both? I'm not totally sure what you mean with when the custom error
handler also has errors. Can you elaborate?
Okay
?php
set_error_handler(myerrorhandler);
function myerrorhandler($errno, $errstr, $errfile, $errline) {
echo There was an error.;
$int = 10 / 0 ; // Divide by zero error
}
echo This will break
?
Which would output something like this:
Error: There was an parse error on line X of file.php.
Additional Error: Custom error handler myerrorhandler() also errored in
line X of file.php
What I mean here is that, allow PHP to have custom error handlers for
core errors instead of just the user-defined errors.
Am I being clear?
John
(and can you please use for quoting mail?)
Derick
--
---
Derick Rethans
http://derickrethans.nl/
JDI Media Solutions
--[
if you hold a unix shell to your ear, do you hear the c? ]-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
On Mon, 18 Nov 2002, John Coggeshall wrote:
Both? I'm not totally sure what you mean with when the custom error
handler also has errors. Can you elaborate?
Okay
?php
set_error_handler(myerrorhandler);
function myerrorhandler($errno, $errstr, $errfile, $errline) {
echo There was an error.;
$int = 10 / 0 ; // Divide by zero error
}
echo This will break
?
Which would output something like this:
Error: There was an parse error on line X of file.php.
Additional Error: Custom error handler myerrorhandler() also errored in
line X of file.php
What I mean here is that, allow PHP to have custom error handlers for
core errors instead of just the user-defined errors.
Core errors are _fatal_ because it leaves the engine in an unclean
state. If you have a parse error then the script hasn't been parsed
fully and thus the compilation step did not even interpreted the tokens
generated by the parse, so how do you want PHP to execute a function then?
Derick
--
---
Derick Rethans http://derickrethans.nl/
JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
John Coggeshall [EMAIL PROTECTED] ha scritto nel messaggio 001201c28ed8$a2fb6620$3801a8c0@cooglewin">news:001201c28ed8$a2fb6620$3801a8c0@cooglewin... |And this can never be supported safely, as a parse error leaves the |parse in an unstable state. Also, I really don't think that we should |try to add hacks to make this possible. Is this directed toward my wish (of having a secondary error if the custom error handler also errors) or toward Mattia's suggestion? Well, I agree that after an E_PARSE the execution must die() and the script can't go on, so when an E_PARSE occurs I havo to choiches (both poor). 1. notify the error on screen (display_errors ...) and let the user know what kind of error is occured, on wich line, on wich file... (NOONE LIKES THIS) 2. interrupt the script in silence and display nothing I would like to be notified of the error, so that I can notify whoever, and the user, that the service is unavaiable and such like an exit function that gets executed on program exit (just before) and whenever the E_PARSE occurs. Mattia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Rasmus Lerdorf [EMAIL PROTECTED] ha scritto nel messaggio [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Well, I certainly don't want errors handled this way for my web apps. Well, would you please tell us why and propose an alternative? Mattia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
I think in a modern web application the error handling function should do
the following:
in case of error (any: parse error, internal application error,)
1. a message should be shown to the user sayng that an error has occured
like an internal error has occured. the webmaster has been notified via
email
2. a more detailed message should be logged in a generic system ErrorLog, or
notified via email or fax, or telephone, or SMS. Depending on the severity
of the error (warning, fatal,...)
On a similar note, I posted a patch a few days ago which was intended
for development environments - it makes error messages appear in a
clear 'window' in the middle of the browser window, so that you don't
have to hunt around in the output of the program to find it. I've
attached it again, in case you're insterested.
John.
Index: main/main.c
===
RCS file: /repository/php4/main/main.c,v
retrieving revision 1.512
diff -u -r1.512 main.c
--- main/main.c 12 Nov 2002 14:40:00 - 1.512
+++ main/main.c 14 Nov 2002 20:57:31 -
@@ -246,6 +246,7 @@
STD_PHP_INI_BOOLEAN(expose_php, 1,
PHP_INI_SYSTEM, OnUpdateBool, expose_php,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY(docref_root, http://www.php.net/;, PHP_INI_ALL,
OnUpdateString, docref_root,php_core_globals,
core_globals)
STD_PHP_INI_ENTRY(docref_ext, ,
PHP_INI_ALL,OnUpdateString, docref_ext,
php_core_globals, core_globals)
+ STD_PHP_INI_BOOLEAN(fancy_html_errors,1,PHP_INI_ALL,
+ OnUpdateBool, fancy_html_errors,
+php_core_globals, core_globals)
STD_PHP_INI_BOOLEAN(html_errors, 1,
PHP_INI_ALL,OnUpdateBool, html_errors,
php_core_globals, core_globals)
STD_PHP_INI_BOOLEAN(xmlrpc_errors,0,
PHP_INI_SYSTEM, OnUpdateBool, xmlrpc_errors,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY(xmlrpc_error_number,0,PHP_INI_ALL,
OnUpdateInt,xmlrpc_error_number,php_core_globals,
core_globals)
@@ -453,7 +454,11 @@
}
}
if (PG(html_errors)) {
- php_error(type, %s(%s) [a href='%s%s%s'%s/a]:
%s, get_active_function_name(TSRMLS_C), params, docref_root, docref, docref_target,
docref, buffer);
+ if (PG(fancy_html_errors)) {
+ php_error(type, div
+style=\position:fixed;left:25%;right:25%;top:25%;bottom:25%;border-style:dashed;border-size:2;background:white;\%s(%s)
+ [a href='%s%s%s'%s/a]: %s/div, get_active_function_name(TSRMLS_C), params,
+docref_root, docref, docref_target, docref, buffer);
+ } else {
+ }
+ php_error(type, %s(%s) [a href='%s%s%s'%s/a]: %s,
+get_active_function_name(TSRMLS_C), params, docref_root, docref, docref_target,
+docref, buffer);
} else {
php_error(type, %s(%s) [%s%s%s]: %s,
get_active_function_name(TSRMLS_C), params, docref_root, docref, docref_target,
buffer);
}
@@ -609,6 +614,9 @@
error_format = PG(html_errors) ?
br /\nb%s/b: %s in b%s/b on line
b%d/bbr /\n
: \n%s: %s in %s on line %d\n;
+ if (PG(fancy_html_errors)) {
+ error_format = div
+style=\position:fixed;left:25%;right:25%;top:25%;bottom:25%;border-style:dashed;border-size:2;background:white;\br
+ /\nb%s/b: %s in b%s/b on line b%d/bbr //div\n;
+ }
if (PG(xmlrpc_errors)) {
error_format = do_alloca(ERROR_BUF_LEN);
snprintf(error_format, ERROR_BUF_LEN-1, ?xml
version=\1.0\?methodResponsefaultvaluestructmembernamefaultCode/namevalueint%ld/int/value/membermembernamefaultString/namevaluestring%%s:%%s
in %%s on line
%%d/string/value/member/struct/value/fault/methodResponse,
PG(xmlrpc_error_number));
Index: main/php_globals.h
===
RCS file: /repository/php4/main/php_globals.h,v
retrieving revision 1.84
diff -u -r1.84 php_globals.h
--- main/php_globals.h 21 Oct 2002 16:41:06 - 1.84
+++ main/php_globals.h 14 Nov 2002 20:57:31 -
@@ -125,6 +125,7 @@
char *docref_ext;
FW: [PHP-DEV] error handling
This is what I sent Derick about a possible method of implementing a custom error handler for E_PARSE, etc... Free to flame if I'm off base here :) -Original Message- From: John Coggeshall [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 3:52 AM To: 'Derick Rethans' Subject: RE: [PHP-DEV] error handling Core errors are _fatal_ because it leaves the engine in an unclean state. If you have a parse error then the script hasn't been parsed fully and thus the compilation step did not even interpreted the tokens generated by the parse, so how do you want PHP to execute a function then? Well, in order for it to work you'd have to be prepared to parse the Error function completely on its own merit... How about this... Create a configuration directive error_handler which accepts one of Two values... Either a PHP script (like auto_prepend) which is responsible For dealing with any (and all) errors which occur, or 'internal' which is Of course the internal PHP handler.. Then, upon script execution if there Is a error_handler script that gets executed and parsed first. If no core Errors occur during the parse/execution of the error handler script then shouldn't The engine be capiable of executing that script upon an error somewhere else? John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
On Mon, 18 Nov 2002, John Bradford wrote: I think in a modern web application the error handling function should do the following: in case of error (any: parse error, internal application error,) 1. a message should be shown to the user sayng that an error has occured like an internal error has occured. the webmaster has been notified via email 2. a more detailed message should be logged in a generic system ErrorLog, or notified via email or fax, or telephone, or SMS. Depending on the severity of the error (warning, fatal,...) On a similar note, I posted a patch a few days ago which was intended for development environments - it makes error messages appear in a clear 'window' in the middle of the browser window, so that you don't have to hunt around in the output of the program to find it. I've attached it again, in case you're insterested. I don't like this patch because it doesn't add anything to PHP itself. You can easily do this with the error_prepend_string and error_append_string configuration settings. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
On Mon, 18 Nov 2002, John Bradford wrote: On a similar note, I posted a patch a few days ago which was intended for development environments - it makes error messages appear in a clear 'window' in the middle of the browser window, so that you don't have to hunt around in the output of the program to find it. I've attached it again, in case you're insterested. You were also told that this functionality can be achieved with error_prepend_string and error_append_string ini settings, so there is no real need for additional functionality. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
On Mon, 18 Nov 2002, John Coggeshall wrote: Core errors are _fatal_ because it leaves the engine in an unclean state. If you have a parse error then the script hasn't been parsed fully and thus the compilation step did not even interpreted the tokens generated by the parse, so how do you want PHP to execute a function then? Well, in order for it to work you'd have to be prepared to parse the Error function completely on its own merit... How about this... Create a configuration directive error_handler which accepts one of Two values... Either a PHP script (like auto_prepend) which is responsible For dealing with any (and all) errors which occur, or 'internal' which is Of course the internal PHP handler.. Then, upon script execution if there Is a error_handler script that gets executed and parsed first. If no core Errors occur during the parse/execution of the error handler script then shouldn't The engine be capiable of executing that script upon an error somewhere else? That can be done, but I don't like this. You should not have any parse errors in your code anyway, so it just should fail as hard as possible. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Monday, November 18, 2002, 11:23:08 AM, Derick Rethans wrote:
That can be done, but I don't like this. You should not have any
parse errors in your code anyway, so it just should fail as hard as
possible.
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. Or a more general command to verify PHP code
php_valid($code_str). That way the people who expect parse errors in
their include files can do
$code_str(implode(, file(include.inc)));
if (php_valid($code_str)) {
include_once(include.inc);
}
--
Kjartan [EMAIL PROTECTED] (http://natrak.net/)
:: Programming is like sex: one mistake and you have to
support it for the rest of your life. - Michael Sinz
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
On Mon, 18 Nov 2002, Kjartan Mannes wrote:
Monday, November 18, 2002, 11:23:08 AM, Derick Rethans wrote:
That can be done, but I don't like this. You should not have any
parse errors in your code anyway, so it just should fail as hard as
possible.
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.
hmm, that might be useful, and would not really be a problem to implemtn
I think, but I'd like to know what the Zend Wizards think of this :)
Or a more general command to verify PHP code
php_valid($code_str). That way the people who expect parse errors in
their include files can do
$code_str(implode(, file(include.inc)));
if (php_valid($code_str)) {
include_once(include.inc);
}
That would be hard, as the zend_compile function which runs the parse
also adds the functions, so if the code parses it includes it right
away. Again, for this one we _could_ not abort the script, but in the
case of include files I'd like to see it die hard again. eval() is
something different in a logical way, but the implementation in the zend
engine is about the same.
Derick
--
---
Derick Rethans http://derickrethans.nl/
JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
I don't like this patch because it doesn't add anything to PHP itself. You can easily do this with the error_prepend_string and error_append_string configuration settings. You were also told that this functionality can be achieved with error_prepend_string and error_append_string ini settings, so there is no real need for additional functionality. Ah, right, sorry about that I didn't read the explaination properly :-). Yes, you're right, it can be done without a patch. What I'm now thinking, though, is that it might be useful to have all of the non-fatal error messages buffered, and output in a visible way at the end. I know you can log to a file, or the system log, but I can't see a way of buffering all errors until the script ends either properly, or with a fatal error. Is this worth working on, or a waste of time? :-) John. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
At 11:39 18-11-2002, Derick Rethans wrote:
[...]
Or a more general command to verify PHP code
php_valid($code_str). That way the people who expect parse errors in
their include files can do
$code_str(implode(, file(include.inc)));
if (php_valid($code_str)) {
include_once(include.inc);
}
That would be hard, as the zend_compile function which runs the parse
also adds the functions, so if the code parses it includes it right
away. Again, for this one we _could_ not abort the script, but in the
case of include files I'd like to see it die hard again. eval() is
something different in a logical way, but the implementation in the zend
engine is about the same.
Since there is '-l'int in the cli, how about a lint function? At least then,
you can verify includes before including them and take any action you want,
including mail().
In a well designed application, you would be able to act on any parse error,
but the 'main' file. Of course this won't work with 'require'.
With kind regards,
Melvyn Sopacua
?php include(not_reflecting_employers_views.txt); ?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
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
more and more of a security-risk and less and less useful... The last
time I've actually seen it implemented in a useful way (that couldn't be
done in a better way) was in PHPLIB. Then again, maybe I'm not coding
things that would need such a function :)
$code_str(implode(, file(include.inc)));
if (php_valid($code_str)) {
include_once(include.inc);
}
That would be hard, as the zend_compile function which runs the parse
also adds the functions, so if the code parses it includes it right
away. Again, for this one we _could_ not abort the script, but in the
case of include files I'd like to see it die hard again. eval() is
something different in a logical way, but the implementation
in the zend
engine is about the same.
What about require'd files?
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...
John
Derick
--
---
Derick Rethans
http://derickrethans.nl/
JDI Media Solutions
--[
if you hold a unix shell to your ear, do you hear the c? ]-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
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. Or a more general command to verify PHP code well, well, well... everybody is talking about E_PARSE but none is talking about E_ERROR. The correct syntax of a program is easy to verify (php -l file). But it's impossible to know if it'll execute correctly without E_ERROR. So to be sure that there will be no E_PARSE is enough to execute it once, but not the same with E_ERROR. Mattia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
On Mon, 18 Nov 2002, Melvyn Sopacua wrote:
At 11:39 18-11-2002, Derick Rethans wrote:
[...]
Or a more general command to verify PHP code
php_valid($code_str). That way the people who expect parse errors in
their include files can do
$code_str(implode(, file(include.inc)));
if (php_valid($code_str)) {
include_once(include.inc);
}
That would be hard, as the zend_compile function which runs the parse
also adds the functions, so if the code parses it includes it right
away. Again, for this one we _could_ not abort the script, but in the
case of include files I'd like to see it die hard again. eval() is
something different in a logical way, but the implementation in the zend
engine is about the same.
Since there is '-l'int in the cli, how about a lint function? At least then,
you can verify includes before including them and take any action you want,
including mail().
In a well designed application, you would be able to act on any parse error,
but the 'main' file. Of course this won't work with 'require'.
IMO parse errors should just kill your script. It's IMO not up to the
language to provide fall back mechanisms for this. If a user too stupid
to use broken files it's their problem.
Derick
--
---
Derick Rethans http://derickrethans.nl/
JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
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? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
uhm, John, we dont have a E_PARSE yet. It's late... I actually stared at that sentence for about 30 seconds trying to determine if I had spelled PARSE wrong... Then I actually went and checked the manual to make sure I hadn't lost my mind and there was actually a E_PARSE constant... Now I'm just confused as to what the heck your talkin' about Derick :) 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. Can't argue about broken code not being a production box. However, dealing with errors in code cleanly (regardless of the problem) is more than just an internal PHP problem. Having a solid way to gracefully bow-out because my cat managed to open, fill with junk, and save a critical include file would just be nice. The choice between the blank screen, or a nasty error message isn't a good one... I'd personally love to have a sorry, our site is hosed error page... If for nothing else then piece of mind... On a secondary note, as Rasmus pointed out when Mattia first suggested his ideas for error handling, everyone's got their own method. This seems like a reasonable and easy way to allow Mattia to SMS, Fax, Call, log, whatever on a critical error without forcing the rest of the PHP community to conform to an entirely new way of doing business. John Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- 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
RE: [PHP-DEV] error handling
On Mon, 18 Nov 2002, John Coggeshall wrote: uhm, John, we dont have a E_PARSE yet. It's late... I actually stared at that sentence for about 30 seconds trying to determine if I had spelled PARSE wrong... Then I actually went and checked the manual to make sure I hadn't lost my mind and there was actually a E_PARSE constant... Now I'm just confused as to what the heck your talkin' about Derick :) hmm, I really thought we didn't have one, as it doesn't make sense at all :) 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. Can't argue about broken code not being a production box. However, dealing with errors in code cleanly (regardless of the problem) is more than just an internal PHP problem. Having a solid way to gracefully bow-out because my cat managed to open, fill with junk, and save a critical include file would just be nice. The choice between the blank screen, or a nasty error message isn't a good one... I'd personally love to have a sorry, our site is hosed error page... If for nothing else then piece of mind... Your cat knows your passwords? :) Anyway, you can always use the error_append_string and error_prepend_string for this. (by putting !-- in prepend_string and -- in append string for example). Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
After all the decision what about an ini directive that makes it possible to send back another file that contains the error message? That would be something like apaches ability to direct some errors to some special pages. The main problem would be how to pass the error information to that script. To overcome such problems i would suggest we'd allow just a simple text file (non php interpreted) and just log the error. marcus At 14:21 18.11.2002, Derick Rethans wrote: On Mon, 18 Nov 2002, John Coggeshall wrote: uhm, John, we dont have a E_PARSE yet. It's late... I actually stared at that sentence for about 30 seconds trying to determine if I had spelled PARSE wrong... Then I actually went and checked the manual to make sure I hadn't lost my mind and there was actually a E_PARSE constant... Now I'm just confused as to what the heck your talkin' about Derick :) hmm, I really thought we didn't have one, as it doesn't make sense at all :) 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. Can't argue about broken code not being a production box. However, dealing with errors in code cleanly (regardless of the problem) is more than just an internal PHP problem. Having a solid way to gracefully bow-out because my cat managed to open, fill with junk, and save a critical include file would just be nice. The choice between the blank screen, or a nasty error message isn't a good one... I'd personally love to have a sorry, our site is hosed error page... If for nothing else then piece of mind... Your cat knows your passwords? :) Anyway, you can always use the error_append_string and error_prepend_string for this. (by putting !-- in prepend_string and -- in append string for example). Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- 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
RE: [PHP-DEV] error handling
hmm, I really thought we didn't have one, as it doesn't make sense at all :) Ha! I'm not crazy! :) Having a solid way to gracefully bow-out because my cat managed to open, fill with junk, and save a critical include file would just be nice. The choice between the blank screen, or a nasty error message isn't a good one... I'd personally love to have a sorry, our site is hosed error page... If for nothing else then piece of mind... Your cat knows your passwords? :) Anyway, you can always use the error_append_string and error_prepend_string for this. (by putting !-- in prepend_string and -- in append string for example). Not true. All I've done in that case is display a half-completed page And hide the fact it died in a comment. Not to mention that doesn't allow For any sort of e-mailing me to let me know my cat hacked my account again (she's a smart little bugger). I guess I just really do believe that PHP's Error handling mechanism has little real use in its current form. There are Better methods of dealing with logic-errors than using trigger_error() if The only thing they are good for is logic-errors... However, If I could handle Every single error that didn't cause some catastrophe seg-fault I feel that It would add a nice capability to the language. Hence, I am still standing by my re-direct (with GET parameters for the nature Of the error :)) suggestion :) John (and his cat) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
John Coggeshall [EMAIL PROTECTED] wrote... : What about require'd files? 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... John I must say that I like this idea. User should be alble to specify the error page in php.ini for different error types and instructing the script to move onto a custom page, leaving the execution of a bad code alone. There would be several reasons why to treat errors gracefuly, even the E_PARSE ones: First reason is to be able to update the current pages in the production server with less risks. When you edit a file on a production site, you might create an E_PARSE error and correct it few seconds later. Not a big deal, but users currently online will be simply told - be back later - server experiences some trouble. Throwing errors on screen includes the full path and can sometimes be a theoretical security risk. Another reason I find for this is, when you do dynamic things like grabbing PHP code from other sources passing it through eval(). That can be out of your control and as such requires a more friendly error treatment. All that provided that an error log is being generated with on line xxx in file xxx but the page is the URL you specify in php.ini. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
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
Re: [PHP-DEV] error handling
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
RE: [PHP-DEV] error handling
?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. Simply fixed if you fix output buffering to ON if you are using a custom re-direct handler for errors. 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.) What are you doing giving users access to eval()??? That's an incredibly huge security risk allowing an arbitary user to execute code of their choosing on your server... (I shiver to think if you actually had the PEAR Inline_C installed).. Besides, as with all of the directives in this nature, a function or two could be created to get/set this directive as necessary from PHP code. 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. Valid, but I'd be careful being too judgemental... I've seen some pretty big web sites doing some pretty stupid things ... Putting untested code on them is sometimes the least of it. John -- 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
Re: [PHP-DEV] error handling
Monday, November 18, 2002, 3:03:39 PM, John Coggeshall wrote: What are you doing giving users access to eval()??? That's an incredibly huge security risk allowing an arbitary user to execute code of their choosing on your server... (I shiver to think if you actually had the PEAR Inline_C installed).. Besides, as with all of the directives in this nature, a function or two could be created to get/set this directive as necessary from PHP code. Selected users with the proper user permissions. What is the point of developing a fine grained user system and not use its power to control the cool stuff? Personally I could live without the option as adding a PHP file is usually faster for me than adding PHP code into a textarea is, but I must admit the latter is quiet handy when you just need a small dynamic page and don't feel like adding more code to the core script just to do it. Also PEAR is a concept I haven't bothered much with yet as the installer has been buggy at best and the code in there doesn't suit my needs. The added level of complexity is unnecessary, and even unwanted if an optimized solution is required. Maybe when it matures more and there is a wider array of packages it will be worth the effort :) Valid, but I'd be careful being too judgemental... I've seen some pretty big web sites doing some pretty stupid things ... Putting untested code on them is sometimes the least of it. So have I. I've also hired, worked with and eventually fired people who didn't get the concept of testing before uploading. Ofcoz I don't test when I update stuff on my own personal sites, but financially they don't cost me anything if they are down all day ;) -- Kjartan [EMAIL PROTECTED] (http://natrak.net/) :: There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. - C.A.R. Hoare -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
At 13:56 18-11-2002, Derick Rethans wrote:
On Mon, 18 Nov 2002, Melvyn Sopacua wrote:
At 11:39 18-11-2002, Derick Rethans wrote:
[...]
Or a more general command to verify PHP code
php_valid($code_str). That way the people who expect parse errors in
their include files can do
$code_str(implode(, file(include.inc)));
if (php_valid($code_str)) {
include_once(include.inc);
}
That would be hard, as the zend_compile function which runs the parse
also adds the functions, so if the code parses it includes it right
away. Again, for this one we _could_ not abort the script, but in the
case of include files I'd like to see it die hard again. eval() is
something different in a logical way, but the implementation in the zend
engine is about the same.
Since there is '-l'int in the cli, how about a lint function? At least
then,
you can verify includes before including them and take any action you want,
including mail().
In a well designed application, you would be able to act on any parse
error,
but the 'main' file. Of course this won't work with 'require'.
IMO parse errors should just kill your script. It's IMO not up to the
language to provide fall back mechanisms for this. If a user too stupid
to use broken files it's their problem.
Refrase with 'one of the people, who has ftp-access to the site, to update
parts
of the HTML'.
Secondly - a parse error is not by definition a 'stupid user' mistake. It
can also
be, because 'short_open_tags' was switched off. It can also be, because in
transit
via FTP the connection died. Or a hickup in the filesystem.
I'd rather have Please wait while we fix this than a half-baked site, or
worse -
a queue of people reloading because nothing shows up.
With kind regards,
Melvyn Sopacua
?php include(not_reflecting_employers_views.txt); ?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] error handling
I think in a modern web application the error handling function should do the following: in case of error (any: parse error, internal application error,) 1. a message should be shown to the user sayng that an error has occured like an internal error has occured. the webmaster has been notified via email 2. a more detailed message should be logged in a generic system ErrorLog, or notified via email or fax, or telephone, or SMS. Depending on the severity of the error (warning, fatal,...) All this done with PHP error handling function (this is not to male distinction between PHP error and application internal error), and the ErrorLog kept via system/server methods (like syslogd). The message shown to the user should be accompained by an HTTP 500 (or more) error. This to make clear to human users that an error has occured therefore the request cannot be fulfilled, and if the cliens is another computer (robot,...) to make it as well (computer look at error codes rather than at things written for humans. I know this is possible now, but not within the error handling function of PHP, or without setting a custom error handler. Mattia Cazzola -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
|I know this is possible now, but not within the error handling |function of PHP, or without setting a custom error handler. Well, it's not really possible now -- a E_PARSE won't get thrown to a custom PHP handler, it'll just die with a parse error. If there is an improvement to be made, perhaps something like what Apache does: Parse Error on line blah blah, Additionaly, there was XYZ error in errorhandle.php. Maybe I can look into this... I'm kinda busy right now though. John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Error Handling
At our web hosting facillity we have several developers (each who recieve a seperate email when an error occurs on the site there working on) and we would like to have extra data included in the log files which are written (such as the $_POST, $_GET, $_ENV, and $_SERVER arrays), this would help us to figure out more precisely why exactly an error occured for a particular user. I already looked at the error_append entry which allows you to append code to an error message but it appears that does not carry over to the log file, is there anyway to make all these arrays dump into the error log after each error entry (I know there is probably a way to do it with some combination of OR and die(customError()) or something, but it would be nice if the built in error handling could do it.). Thanks, Adam Voigt [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
