|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2006-08-04 15:06 UTC] RQuadling at GMail dot com
Description:
------------
Using trigger_error/user_error only reports where the error was raised.
This is OK in most instances, but if the code is triggering an error due to a problem with a functions parameters, it would be useful to know where the call was made from.
So, using the debug_backtrace() function, the first element in the array can be used to find the file and line number of the original call.
But, if you combine that with trigger_error/user_error, you also get the file and line of the trigger statement.
The following code is an example showing a standard PHP produced error for an incorrect parameter and a user generated error along similar lines.
As you can see from the output, the second message is wrapped with the error for the trigger.
Ideally, a parameter to NOT show the additional data, but just use the error message EXACTLY as generated would be great. Or to be able to indicate that the file and line number to use is x levels in the backtrace (0 would be the default indicating the current file and line, 1 would be the caller if it is a function or a method, 2+ would be further down the trace and probably not much use).
I've looked at zend_builtin_functions.c (/* $Id: zend_builtin_functions.c,v 1.322 2006/07/27 08:20:52 dmitry Exp $ */ Lines 1207 - 1244) and zend_error (zend.c /* $Id: zend.c,v 1.368 2006/07/24 17:51:40 helly Exp $ */ Lines 1367+).
To no avail (I'm still too newbie to do to much source moding).
The example is all in 1 file, but if the function was in a library file somewhere, and was 1 class per file, finding the error COULD take WAY too long.
Reproduce code:
---------------
<?php
// Demonstrate a normal error.
$dummy = '';
echo sort($dummy);
function first_param_not_array($data)
{
if (is_array($data))
{
$a_Debug = debug_backtrace();
trigger_error("first_param_not_array() expects parameter 1 to not be an array, array given in {$a_Debug[0]['file']} on line {$a_Debug[0]['line']}", E_USER_WARNING);
}
}
// Demonstrate the user error issue.
first_param_not_array($_ENV);
?>
Expected result:
----------------
Warning: sort() expects parameter 1 to be array, string given in C:\user_gen_error.php on line 4
Warning: first_param_not_array() expects parameter 1 to not be an array, array given in C:\user_gen_error.php on line 16
Actual result:
--------------
Warning: sort() expects parameter 1 to be array, string given in C:\user_gen_error.php on line 4
Warning: first_param_not_array() expects parameter 1 to not be an array, array given in C:\user_gen_error.php on line 16 in C:\user_gen_error.php on line 11
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Mon Oct 27 21:00:02 2025 UTC |
It would still (after 6 years) be great if third parameter would be supported by the trigger_error function. Description of functionality requested to be supported: bool trigger_error ( string $error_msg [, int $error_type = E_USER_NOTICE [, int $backstep = 0]] ) The point of the third argument is to control from which stack frame the file and line number will be reported in the error string. The requested functionality can be replicated in PHP; an example: /** * @example * * error('Data is not valid UTF-8, assuming ISO 8859-1 (Latin-1) encoding', E_USER_NOTICE, 3); * * @param string $error_msg (unchanged from current functionality) * @param int $error_type (unchanged from current functionality) * @param int $backstep the number of stack frames to go back in the backtrace, defaults to 0 */ function error($error_msg, $error_type, $backstep = 0) { // For clarity, no checks on validity of the function call arguments are included in this example $callStack = debug_backtrace(); trigger_error( $error_msg.', called in '.$callStack[$backstep]['file'].' on line '.$callStack[$backstep]['line'] , $error_type ); } So, why this request for adding a third parameter if the functionality can be replicated in PHP? When creating open source libraries, we aim for as minimal a set of dependencies as possible while still writing the best possible code as possible. If the open source community can not give user friendly errors/warnings/notices without the need for a custom dependency, chances are they will just go for either an Exception (which serves a different purpose) or don't give any error description at all.