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
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
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
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:
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
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
- 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.
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:
- 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
You could submit your extension to http://pecl.php.net if you'd like
to encourage others to make use of it.
--Wez.
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:
- 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