php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #38332 trigger_error doesn't show where the error occurred.
Submitted: 2006-08-04 15:06 UTC Modified: 2017-01-29 04:22 UTC
Votes:3
Avg. Score:4.3 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: RQuadling at GMail dot com Assigned:
Status: No Feedback Package: *General Issues
PHP Version: 5.2.0RC1 OS: Windows XP SP2
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: RQuadling at GMail dot com
New email:
PHP Version: OS:

 

 [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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-08-04 15:17 UTC] tony2001@php.net
Changind 
function first_param_not_array($data)
to
function first_param_not_array(array $data)
does it for you automatically.
 [2006-08-04 15:21 UTC] RQuadling at GMail dot com
No.

I DON'T want an array as the first parameter. Type hinting works for arrays and classes, but not other types.

The error is when an array is supplied and __NOT__ wanted!!!!

I know this is an obtuse issue, the real issue is I want to generate a user error but have the calling line id'd as the fault, not the trigger_error() line as there is nothing wrong there.
 [2012-07-16 14:22 UTC] notdefix at hotmail dot com
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.
 [2017-01-20 21:58 UTC] heiglandreas@php.net
-Status: Open +Status: Feedback -Package: Feature/Change Request +Package: *General Issues
 [2017-01-20 21:58 UTC] heiglandreas@php.net
Is this still relevant?
 [2017-01-29 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 27 11:01:30 2024 UTC