php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #27122 additional directives for declare (and other event trappers possibly)
Submitted: 2004-02-02 16:59 UTC Modified: 2018-05-05 17:36 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: nutbar at innocent dot com Assigned:
Status: Wont fix Package: *General Issues
PHP Version: Irrelevant OS: Irrelevant
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: nutbar at innocent dot com
New email:
PHP Version: OS:

 

 [2004-02-02 16:59 UTC] nutbar at innocent dot com
Description:
------------
Just a low priority feature request...

I thought it would be rather nice to have additional directives which the declare control structure could capture.  Such events would be (for example):

function entrance
function exit
runtime script parser status (ie, just traces what position the parser is at in any script)
... others that I might have omitted to think of...

This could potentially allow a replacement of user error logging that would allow greater flexibility - we could now trace what function we're in (and keep track of) as well as which ones we exit, and also allow a line,character tracking as the PHP parser runs (or maybe even initial compiling of!) the code.  This could even allow the ability to finally use user logging code to log E_PARSE errors and other stuff (maybe?).

I'm not sure if I'm describing this enough as I think about what I'm thinking could be done - but hopefully whoever reads this can understand the potential benefits to being able to track various different core events aside from just "ticks".

Expected result:
----------------
Just one side note - if it was made possible to trap E_PARSE (or even E_ERROR) error events, the posibility of having an error message that read like:

parse error: missing '}' in /some/script.php on line 5 ultimately generated from /other/script.php on line 12

The reason would be that if you did trap a parse error or something - PHP wouldn't obviously be able to execute the failed code, but potentially could make special cases for the declare control structure (or any event trapping function) and compile that before anything else so that it could still be executed in the event of other script errors.  If so, then if *that* code (the code in the declare control structure) had an error, you could get an error within an error.

Hope that made sense :)

If it did, the possibility of an error (or other events) trapping "loop" could arise - so maybe just ignore *this* part of the feature request (probably not feasable to try and trap such low level errors).


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-05-05 17:36 UTC] requinix@php.net
-Status: Open +Status: Wont fix -Package: Feature/Change Request +Package: *General Issues
 [2018-05-05 17:36 UTC] requinix@php.net
Old request is old.

This sort of thing sounds like the job for an extension and not userland PHP code, but if anyone is still interested in making this happen then check out the RFC process. https://wiki.php.net/rfc/howto
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 08:01:27 2024 UTC