# Patch for php_error_cb

- Thread: https://externals.io/message/16259
- Original archive: https://news-web.php.net/php.internals/16259
- Started by Blake Matheny on 2005-05-16T19:16:19+00:00
- Messages: 8
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #16259 — Blake Matheny — 2005-05-16T19:16:19+00:00

URL: https://externals.io/message/16259#16259

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

---

## #16260 — George Schlossnagle — 2005-05-16T22:41:36+00:00

URL: https://externals.io/message/16259#16260 · In reply to: #16259

> 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

---

## #16263 — Derick Rethans — 2005-05-17T11:04:01+00:00

URL: https://externals.io/message/16259#16263 · In reply to: #16260

> 
> 
> 
> > […]
> 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

---

## #16264 — Blake Matheny — 2005-05-17T12:04:10+00:00

URL: https://externals.io/message/16259#16264 · In reply to: #16263

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:
> 
> 
> > […]
> 
> 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

---

## #16265 — George Schlossnagle — 2005-05-17T13:07:46+00:00

URL: https://externals.io/message/16259#16265 · In reply to: #16264

> 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

---

## #16266 — Wez Furlong — 2005-05-17T14:09:24+00:00

URL: https://externals.io/message/16259#16266 · In reply to: #16264

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

---

## #16267 — Blake Matheny — 2005-05-17T14:22:04+00:00

URL: https://externals.io/message/16259#16267 · In reply to: #16266

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:
> 
> > […]
> 
> But you still need to write a custom shared library, so this is not
> such a great point.
> 
> > […]
> 
> But you still need to write a custom shared library.
> 
> > […]
> 
> I don't think those two points are relevant.
> 
> > […]
> 
> 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

---

## #16268 — Wez Furlong — 2005-05-17T14:26:13+00:00

URL: https://externals.io/message/16259#16268 · In reply to: #16267

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:
> > […]
> 
> --
> Blake Matheny
> 3GUpload.com, Inc.
> Director of Technology
> 317-472-4962 (W)
> 317-201-2840 (C)
> bmatheny@3gupload.com