Grokbase › Groups › PHP › php-internals › May 2005
FAQ
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)
[email protected]

Search Discussions

  • George Schlossnagle at May 16, 2005 at 11:02 pm ⇧

    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 at May 17, 2005 at 11:22 am ⇧

    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 at May 17, 2005 at 12:11 pm ⇧
    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)
    [email protected]
  • George Schlossnagle at May 17, 2005 at 1:26 pm ⇧

    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 at May 17, 2005 at 2:24 pm ⇧

    On 5/17/05, Blake Matheny 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 at May 17, 2005 at 3:06 pm ⇧
    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 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)
    [email protected]
  • Wez Furlong at May 17, 2005 at 3:31 pm ⇧
    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 wrote:
    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 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)
    [email protected]

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 16, '05 at 7:33p
activeMay 17, '05 at 3:31p
posts8
users4
websitephp.net

4 users in discussion

Blake Matheny: 3 posts George Schlossnagle: 2 posts Wez Furlong: 2 posts Derick Rethans: 1 post

Content

People

Support

Translate

site design / logo © 2023 Grokbase