This bit me in the arse today.
Errors that are genuine errors and tracked through PHP's error handler will have file and line numbers attached because they're passed from PHP itself. But errors issued through fatal_lang_error and fatal_error, that when passed to log_error... they will not have file and/or line numbers.
There's a certain logic to that, actually, in that there's not really a need to pack out the DB with file/line numbers when it's issued by the code itself in response to a user event/other failure condition, rather than an 'error' in the classical sense.
Trouble is, this also means plugins that call fatal_lang_error also won't get logged as being under their plugin unless they specifically pass their plugin id to the error handler, which is kludgy at best.
There's two courses. Either way I can grab the backtrace and get the file/line it came from. The question, really, is whether for general errors (rather than undefined variables etc) that the file and line should be logged. From a debugging perspective it'd be useful, but I'm not sure the user needs to be presented with the file/line every time.
What I'm going to do for now is to keep it mostly as it is, but if no file is found, grab the filename, identify if it's a plugin or not, and then bar logging the file/line number. But the option's open if people want it.
(I'm also debating providing the full backtrace in the error log for debugging purposes, which would be very useful sometimes.)
Errors that are genuine errors and tracked through PHP's error handler will have file and line numbers attached because they're passed from PHP itself. But errors issued through fatal_lang_error and fatal_error, that when passed to log_error... they will not have file and/or line numbers.
There's a certain logic to that, actually, in that there's not really a need to pack out the DB with file/line numbers when it's issued by the code itself in response to a user event/other failure condition, rather than an 'error' in the classical sense.
Trouble is, this also means plugins that call fatal_lang_error also won't get logged as being under their plugin unless they specifically pass their plugin id to the error handler, which is kludgy at best.
There's two courses. Either way I can grab the backtrace and get the file/line it came from. The question, really, is whether for general errors (rather than undefined variables etc) that the file and line should be logged. From a debugging perspective it'd be useful, but I'm not sure the user needs to be presented with the file/line every time.
What I'm going to do for now is to keep it mostly as it is, but if no file is found, grab the filename, identify if it's a plugin or not, and then bar logging the file/line number. But the option's open if people want it.
(I'm also debating providing the full backtrace in the error log for debugging purposes, which would be very useful sometimes.)
