# Bogus bug??

- Thread: https://externals.io/message/21175
- Original archive: https://news-web.php.net/php.internals/21175
- Started by Robert Cummings on 2005-12-11T22:26:40+00:00
- Messages: 5
- 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

---

## #21175 — Robert Cummings — 2005-12-11T22:26:40+00:00

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

Could someone explain to my feeble mind how the bug reported at the
following link is bogus? The added comment is pretty obtuse :(

    http://bugs.php.net/bug.php?id=35634&edit=2

Thanks,
Rob.
-- 
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

---

## #21176 — Robert Cummings — 2005-12-11T22:55:05+00:00

URL: https://externals.io/message/21175#21176 · In reply to: #21175

> Could someone explain to my feeble mind how the bug reported at the
> following link is bogus? The added comment is pretty obtuse :(
> 
>     http://bugs.php.net/bug.php?id=35634&edit=2

I'd just like to add before a second person send me an RTFM type email,
that I HAVE read the documentation for `set_error_handler()` and I am
aware that it says that most `E_STRICT` errors can't be handled if they
occur in the same file as the `set_error_handler()` call. The `E_STRICT` I'm
attempting to catch however, is in another script. Maybe it's the same
thing because I include the code, or I guess more than likely because it
happens at parse time, but either way, I'm not nesting classes the
parser just thinks I am which I thus categorize as a parser bug. Also it
seems somewhat ironic that an attempt to catch an `E_STRICT` causes an
E_FATAL *lol*.

Thanks,
Rob.
-- 
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

---

## #21177 — Bart de Boer — 2005-12-12T00:02:37+00:00

URL: https://externals.io/message/21175#21177 · In reply to: #21176

Robert Cummings wrote:
> 
> 
> Could someone explain to my feeble mind how the bug reported at the
> following link is bogus? The added comment is pretty obtuse :(
> 
>    http://bugs.php.net/bug.php?id=35634&edit=2
> 
> Thanks,
> Rob.

It looks like each time your errorHandler function is called it is 
trying to (re)declaring ErrorClass, causing the error. If you take 
require_once('errorClass.php'); out of the errorHandler function, it 
works as expected.

Bart

---

## #21178 — Robert Cummings — 2005-12-12T00:31:38+00:00

URL: https://externals.io/message/21175#21178 · In reply to: #21177

> Robert Cummings wrote:
> > […]
>
> It looks like each time your errorHandler function is called it is 
> trying to (re)declaring ErrorClass, causing the error. If you take 
> require_once('errorClass.php'); out of the errorHandler function, it 
> works as expected.

This sample on the bug report is actually a very whittled down version
of where I first experienced the problem. In practice my error class is
loaded on first error and subsequently acts as a singleton. My thoughts
on the problem are that PHP encounters an `E_STRICT` exception in
testClass.php during the parse, so it invokes the error handler, the
error handler then loads the error class, but because the error itself
occured during the parsing of a class PHP still thinks it's parsing the
class and so when errorClass.php is parsed it fires the fatal error for
class nesting. IMHO that's a parser bug since PHP should (as it normally
does) consider an included/required class description to be outside the
the inclusion scope.

As an FYI, the reason i use this technique is because my framework uses
a registry type system for modular system services that are lazy loaded,
one of which is the exception service. I guess I missed this problem in
earlier versions of PHP5 because I filter out `E_STRICT` notices in the
wrapper function that I refuse to correct in my engine for PHP4
compatibility reasons (I currently filter 3). But it raises the issue
that anytime a new `E_STRICT` type error is created that I may not have
addressed yet, the result is a fatal error instead of an annoying
 `E_STRICT` :)

Cheers,
Rob.
-- 
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

---

## #21187 — Bart de Boer — 2005-12-12T08:06:49+00:00

URL: https://externals.io/message/21175#21187 · In reply to: #21178

Robert Cummings wrote:
> 
> This sample on the bug report is actually a very whittled down version
> of where I first experienced the problem. In practice my error class is
> loaded on first error and subsequently acts as a singleton. My thoughts
> on the problem are that PHP encounters an `E_STRICT` exception in
> testClass.php during the parse, so it invokes the error handler, the
> error handler then loads the error class, but because the error itself
> occured during the parsing of a class PHP still thinks it's parsing the
> class and so when errorClass.php is parsed it fires the fatal error for
> class nesting. IMHO that's a parser bug since PHP should (as it normally
> does) consider an included/required class description to be outside the
> the inclusion scope.
> 
> As an FYI, the reason i use this technique is because my framework uses
> a registry type system for modular system services that are lazy loaded,
> one of which is the exception service. I guess I missed this problem in
> earlier versions of PHP5 because I filter out `E_STRICT` notices in the
> wrapper function that I refuse to correct in my engine for PHP4
> compatibility reasons (I currently filter 3). But it raises the issue
> that anytime a new `E_STRICT` type error is created that I may not have
> addressed yet, the result is a fatal error instead of an annoying
> `E_STRICT` :)
> 
> Cheers,
> Rob.

It looks like it happens the way you say. And I'm afraid I don't know if 
this is by PHP's design or not.

Regarding the FMY. Shouldn't error handling be something that is part of 
your framework? And not part of your plugin modules? That's the way I 
consider it with my modular apps at least. :)

Bart