# [path] fixing errors, take 2

- Thread: https://externals.io/message/51081
- Original archive: https://news-web.php.net/php.internals/51081
- Started by Stas Malyshev on 2010-12-19T03:31:45+00:00
- Messages: 4
- 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

---

## #51081 — Stas Malyshev — 2010-12-19T03:31:45+00:00

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

Hi!

Since my first attempt to make error reporting in PHP more efficient 
(see epic thread here: 
http://www.pubbs.net/200908/php/49633-php-dev-patch-error-masks.html) I 
thought about another approach to fixing it.
This approach eliminates the need for additional .ini setting and 
shortcuts only those errors that would not have any consequences - i.e. 
would not be displayed, logged, stored, converted to exception or 
otherwise have any effect on the outside world. The benefit of this 
approach is obvious - nothing changes for the user, only the code runs 
faster. The cost is that we add one handler to utility_functions and 
thus code that overrides error callback (debuggers, etc.) would have to 
provide their own handler if they want the same functionality (by 
default if this handler detects somebody stole error callback it turns off).
The patch is attached.
Any objections for trunk?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #51083 — hannes.magnusson@gmail.com — 2010-12-19T09:13:55+00:00

URL: https://externals.io/message/51081#51083 · In reply to: #51081

> Hi!
>
> Since my first attempt to make error reporting in PHP more efficient (see
> epic thread here:
> http://www.pubbs.net/200908/php/49633-php-dev-patch-error-masks.html) I
> thought about another approach to fixing it.
> This approach eliminates the need for additional .ini setting and shortcuts
> only those errors that would not have any consequences - i.e. would not be
> displayed, logged, stored, converted to exception or otherwise have any
> effect on the outside world. The benefit of this approach is obvious -
> nothing changes for the user, only the code runs faster. The cost is that we
> add one handler to utility_functions and thus code that overrides error
> callback (debuggers, etc.) would have to provide their own handler if they
> want the same functionality (by default if this handler detects somebody
> stole error callback it turns off).
> The patch is attached.
> Any objections for trunk?

AFAICT from the patch..
if (@strpos()) {} else { var_dump(error_get_last()); }
will give you the last error that happened before `strpos()`?

-Hannes

---

## #51084 — Stas Malyshev — 2010-12-19T09:56:47+00:00

URL: https://externals.io/message/51081#51084 · In reply to: #51083

Hi!

> AFAICT from the patch..
> if (@strpos()) {} else { var_dump(error_get_last()); }
> will give you the last error that happened before `strpos()`?

Hmm... that unfortunately depends on ignore_repeated_errors, I didn't 
see this use case. With `error_get_last()` we probably can't fix it since 
it requires storing full error message for every error. That kind of 
sucks :(
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #51085 — hannes.magnusson@gmail.com — 2010-12-19T10:03:09+00:00

URL: https://externals.io/message/51081#51085 · In reply to: #51084

> Hi!
>
> > […]
>
> Hmm... that unfortunately depends on ignore_repeated_errors, I didn't see
> this use case. With `error_get_last()` we probably can't fix it since it
> requires storing full error message for every error. That kind of sucks :(

I like the idea behind the patch, and I cannot think of a clean way
around the `error_get_last()` problem.
 `error_get_last()` also has issues with user defined error handler, so I
suppose we should just document it properly..

-Hannes