On Tue, May 7, 2013 at 3:38 PM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> Hi! > > > So the error messages your library produces have the same consistent > > look and feel to them that PHP's errors do? > > While it may be nice, I don't think it is worth changing the PHP API > for. Error messages have very defined api, which has the place in the > source where they were actually produced. > So just redefine the API lol. ie. make it so trigger_error has this as its function definition: bool trigger_error ( string $error_msg [, int $error_type = E_USER_NOTICE [, string $errfile = __FILE__ [, int $errnum = __LINE__ ]]] ) > > > Besides, keeping in mind the KISS "keep it simple stupid" principal > > gratuitous information should probably be hidden away. I mean if it's > > not going to help anyone then the only thing left for it to do is > > potentially confuse people. And why risk that? > > The place where the error is produced is definitely helpful. Now, it may > not be *all* the information you need, but error messages are simple > things, they are not meant to replace debugger with full backtrace and > stack inspection. I don't think it needs added complications just to > have some library messages look a little nicer. > In any case, one can install custom error handler which would format > messages for user errors differently, if desired. > > You shouldn't need to load up a debugger with a full backtrace and stack inspection to figure out (from my previous example) that you had a divide by 0 error. That said I will concede the "look a little nicer" point. I guess, in my mind, it's really just a matter of how many code changes would be required. If 10,000 lines of code in PHP would have to be changed... it's not worth it. If all you'd be modifying are two lines of code... doesn't seem like such a big deal to me. Besides, what if a program already has an error handler defined?
