Re: [PHP-DEV] error handling

[Ivan Ristic]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[James Cox]

>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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[James Cox]

>
> 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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[James Cox]

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

[Ivan Ristic]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Derick Rethans]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Ivan Ristic]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[Mike Robinson]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>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

[Maxim Maletsky]

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

[Nick Loman]

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 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Maxim Maletsky]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Ivan Ristic]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Ivan Ristic]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Edin Kadribasic]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[Derick Rethans]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[Derick Rethans]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>
>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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[Stig S. Bakken]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>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

[Ivan Ristic]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[Chris Shiflett]

--- 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.

How do you think PHP is able to change the HTTP response code when
someone uses a header("Location: ...") in their code? :-)

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.

Chris

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[James Cox]

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

[Ray Hunter]

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

[James Cox]

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

[John Coggeshall]

>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

[John Coggeshall]

|>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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Stig S. Bakken]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Ivan Ristic]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Ivan Ristic]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Melvyn Sopacua]

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 Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Kjartan Mannes]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>> 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Maxim Maletsky]

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:
> 
> > 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 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Kjartan Mannes]

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:

> 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.



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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Maxim Maletsky]

"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:
> 
> 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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>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 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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[Marcus Börger]

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 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 
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[Derick Rethans]

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 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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>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 
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[Derick Rethans]

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:
> 
> 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Derick Rethans]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Mattia]

> 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
). 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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>> 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:

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Melvyn Sopacua]

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 Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[John Bradford]

> 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Derick Rethans]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Kjartan Mannes]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[Derick Rethans]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Edin Kadribasic]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Derick Rethans]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[John Bradford]

> 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) [%s]: 
%s", get_active_function_name(TSRMLS_C), params, docref_root, docref, docref_target, 
docref, buffer);
+   if (PG(fancy_html_errors)) {
+   php_error(type, "%s(%s)
+ [%s]: %s", get_active_function_name(TSRMLS_C), params, 
+docref_root, docref, docref_target, docref, buffer);
+   } else {
+   }   
+   php_error(type, "%s(%s) [%s]: %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) ?
"\n%s:  %s in %s on line 
%d\n"
: "\n%s: %s in %s on line %d\n";
+   if (PG(fancy_html_errors)) {
+   error_format = "\n%s:  %s in %s on line %d\n";
+   }
if (PG(xmlrpc_errors)) {
error_format = do_alloca(ERROR_BUF_LEN);
snprintf(error_format, ERROR_BUF_LEN-1, "faultCode%ldfaultString%%s:%%s
 in %%s on line 
%%d", 
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;
 
zend_bool html_errors;
+   zend_bool fancy_html_errors;
zend_bool xmlrpc_errors;
 
long xmlrpc_error_number;


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Mattia]

"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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Mattia]

"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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[Derick Rethans]

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
> 
>  
>   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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>Both? I'm not totally sure what you mean with "when the custom error 
>handler also has errors". Can you elaborate?

Okay



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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[Rasmus Lerdorf]

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 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[Derick Rethans]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

|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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[Derick Rethans]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

|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 
To unsubscribe, visit: http://www.php.net/unsub.php