# issue of current E_STRICT implemention and possible solution

- Thread: https://externals.io/message/25900
- Original archive: https://news-web.php.net/php.internals/25900
- Started by phpxcache on 2006-10-01T11:48:46+00:00
- Messages: 1
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #25900 — phpxcache — 2006-10-01T11:48:46+00:00

URL: https://externals.io/message/25900#25900

the `E_STRICT` is an error type that issued at compile-time. and user
error handler is called, switching to runtime. mixing
runtime/compile-time is imho, not good, and cause problem in the real
world.

the flow:
script, include -> compiling, issue `E_STRICT` -> user error handler.

official bug:
1. set up user error handler
2. issue `E_STRICT` inside class compiling

function my_error_handler()
{
   include_once "debugger.class.php"; // #1
   $dbg = Debugger::getInstance();
   ...
}

is the behavior defined at point #1 ? if it is allowed, what if wrote
"class Debugger { ..." into debugger.class.php ? it just tell me "u
cannot declare class inside another class" (something like this)

3rd party bug:
XCache is doing nice on late class binding by building "compiler
sandbox" for ZendEngine, which clear class_table/function_table
temporarily, to make the compiler-env exactly the same every time.

but inside the sandbox, functions/classes defined before compiling, is
never exists inside the compile-time, leading to a "undefined
function" or "undefined class" error inside user error handler.

yes, the author should hack, but it's better done in php-src or ZendEngine side.

solution propose:
1. never call user error handler for `E_STRICT` 
2. add `E_STRICT` to pending list and issue it after compiling. (after
returning from compile_file)