Everything

php

Patch for php_error_cb

php.internals

Blake Matheny

21 years ago

Attached is a small patch that allows for a custom error handler to be
used instead of php_log_err. This is useful for custom logging of error
types that can't be handled with a user-space error handler (such as
E_ERROR, E_PARSE, etc.).

In order to use a custom error handler set error_log to so:/path/to/so
in the php.ini file, where the shared object has a function called
error_handler with the following prototype:

int error_handler(int type,
const char *error_filename,
const unsigned int error_lineno,
const char *format,
va_list args)

error_handler should return a non-zero integer if the error was
successfully handled and zero otherwise.

We are using this patch to log errors to a MySQL database for our defect
tracking system.

Regards,

Blake

--
Blake Matheny
3GUpload.com, Inc.
Director of Technology
317-472-4962 (W)
317-201-2840 (C)
bmatheny@3gupload.com

George Schlossnagle

21 years ago

On May 16, 2005, at 3:16 PM, Blake Matheny wrote:

> Attached is a small patch that allows for a custom error handler to
> be used instead of php_log_err. This is useful for custom logging
> of error types that can't be handled with a user-space error
> handler (such as E_ERROR, E_PARSE, etc.).
>
> In order to use a custom error handler set error_log to so:/path/to/
> so in the php.ini file, where the shared object has a function
> called error_handler with the following prototype:
>

This is already possible without your patch: just write a php
extension and change the zend_error_cb function pointer to your
custom C function in MINIT.

George

Derick Rethans

21 years ago

On Mon, 16 May 2005, George Schlossnagle wrote:

>
> On May 16, 2005, at 3:16 PM, Blake Matheny wrote:
>
> > Attached is a small patch that allows for a custom error handler to be used
> > instead of php_log_err. This is useful for custom logging of error types
> > that can't be handled with a user-space error handler (such as E_ERROR,
> > E_PARSE, etc.).
> >
> > In order to use a custom error handler set error_log to so:/path/to/so in
> > the php.ini file, where the shared object has a function called
> > error_handler with the following prototype:
> >
> This is already possible without your patch: just write a php extension and
> change the zend_error_cb function pointer to your custom C function in MINIT.

But make sure you call the original one after that... otherwise you
might break other extensions that modify the error_cb (like Xdebug).

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Blake Matheny

21 years ago

Is there anything incorrect/wrong with the solution I proposed? I
realize that a custom extension would also work, but there are several
advantages to doing it the way I implemented it

- No need to add an extension every time you upgrade PHP
- No additional patching (which an extension essentially requires)
- Only adds a couple of extra operations (no performance hit)
- Backwards compatible with existing php.ini
- Possibility for other prefixes (script:,file:,socket:,etc)

Obviously I'd like this included in the tree, and if it won't be
possible in the current implementation how should it be done? Ultimately
having something like this that is just part of PHP is ideal from a
maintenance standpoint. Thanks for the input.

- Blake

Derick Rethans wrote:

> On Mon, 16 May 2005, George Schlossnagle wrote:
>
>>On May 16, 2005, at 3:16 PM, Blake Matheny wrote:
>>
>>>Attached is a small patch that allows for a custom error handler to be used
>>>instead of php_log_err. This is useful for custom logging of error types
>>>that can't be handled with a user-space error handler (such as E_ERROR,
>>>E_PARSE, etc.).
>>>
>>>In order to use a custom error handler set error_log to so:/path/to/so in
>>>the php.ini file, where the shared object has a function called
>>>error_handler with the following prototype:
>>>
>>This is already possible without your patch: just write a php extension and
>>change the zend_error_cb function pointer to your custom C function in MINIT.
>
> But make sure you call the original one after that... otherwise you
> might break other extensions that modify the error_cb (like Xdebug).
>
> Derick

--
Blake Matheny
3GUpload.com, Inc.
Director of Technology
317-472-4962 (W)
317-201-2840 (C)
bmatheny@3gupload.com

George Schlossnagle

21 years ago

On May 17, 2005, at 8:04 AM, Blake Matheny wrote:

> Is there anything incorrect/wrong with the solution I proposed? I
> realize that a custom extension would also work, but there are
> several advantages to doing it the way I implemented it
>
> - No need to add an extension every time you upgrade PHP

You can of course dynamically load extensions from your ini, and they
only need to change when the API version changes.  What you have is
essentially a special purpose extension.

The situation is that you want to provide an alternative type of
extension to accomplish something that can already be accomplished
through an extension (and which was designed to support exactly the
things you're trying to do (and more)).  That sort of redundancy
isn't very useful.

George

Wez Furlong

21 years ago

On 5/17/05, Blake Matheny <bmatheny@3gupload.com> wrote:

> - No need to add an extension every time you upgrade PHP

But you still need to write a custom shared library, so this is not
such a great point.

> - No additional patching (which an extension essentially requires)

But you still need to write a custom shared library.

> - Only adds a couple of extra operations (no performance hit)
> - Backwards compatible with existing php.ini

I don't think those two points are relevant.

> - Possibility for other prefixes (script:,file:,socket:,etc)

This is the only plus point in your argument, but you should consider
that we already have a mechanism for logging to files, and no one has
asked to be able to log to anything else for quite some time.

I think you really need to do some convincing to get the patch in, and
I don't see many benefits to the majority of PHP users with the patch
as it stands now.

--Wez.

Blake Matheny

21 years ago

After George's comments, I think I'll just write up an extension and
throw it out there. I can still support a script:,file:,socket:,sql:
convention for naming and meet all of my requirements. Thanks for the
feedback.

-Blake

Wez Furlong wrote:

> On 5/17/05, Blake Matheny <bmatheny@3gupload.com> wrote:
>>- No need to add an extension every time you upgrade PHP
>
> But you still need to write a custom shared library, so this is not
> such a great point.
>
>>- No additional patching (which an extension essentially requires)
>
> But you still need to write a custom shared library.
>
>>- Only adds a couple of extra operations (no performance hit)
>>- Backwards compatible with existing php.ini
>
> I don't think those two points are relevant.
>
>>- Possibility for other prefixes (script:,file:,socket:,etc)
>
> This is the only plus point in your argument, but you should consider
> that we already have a mechanism for logging to files, and no one has
> asked to be able to log to anything else for quite some time.
>
> I think you really need to do some convincing to get the patch in, and
> I don't see many benefits to the majority of PHP users with the patch
> as it stands now.
>
> --Wez.

--
Blake Matheny
3GUpload.com, Inc.
Director of Technology
317-472-4962 (W)
317-201-2840 (C)
bmatheny@3gupload.com

Wez Furlong

21 years ago

You could submit your extension to http://pecl.php.net if you'd like
to encourage others to make use of it.

--Wez.

On 5/17/05, Blake Matheny <bmatheny@3gupload.com> wrote: