> User defined error handler is for error handling customization, letting > user > customize message makes sense.
This is exactly our case. > Thomas, > If there are many people concerns to change error message, how about > append user error message to original error message when it's changed? > It's a hacky behavior to me, though. I see no difference if the userland developer can extend (or even change) error messages if he can completely disable (using @, return true in the callback, etc.). Of course it is our task to inform about best practices in the php manual and warn about bad things. Regards Thomas Yasuo Ohgaki wrote on 29.01.2015 03:51: > Hi Andrea, > > On Thu, Jan 29, 2015 at 2:38 AM, Andrea Faulds <a...@ajf.me> wrote: > >> Error handlers are global anyway, so this is useless (or dangerous) for >> libraries. > > > I suggest library/framework developers *not* to use user defined error > handler. > It's better to leave error handler for application developers. > > I strongly suggest application developers to use user defined error handler > to catch > unexpected problems. > > If app codes are written not to raise errors under normal operations (which > I strongly > recommend to do so), errors are sign of system problems. e.g. Subsystem is > down, > misconfiguration, crackers are attacking system, etc. > > In case of attack, admins would like to know which account is causing the > problem. Error message like "Warning: failed to write /etc/passwd" is less > useful than "Warning: failed to write /etc/passwd. User: yohgaki". > > User defined error handler is for error handling customization, letting > user > customize message makes sense. > > Thomas, > If there are many people concerns to change error message, how about > append user error message to original error message when it's changed? > It's a hacky behavior to me, though. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
