Colleen Dick írta:
> I also stalled out on using this, just because the doc was so old and did
> not match what I was seeing. It really looks like it would be a nice
> package if it had a little usability enginnerring, internals doc and was
> brought up to at least php 4.2

Sorry for the inconvenience once again.

BTW, if there are so many impressed men out there what is missing to become
volunteers? ;)
I attached what was in my mind for 6 or 7 months, where to move on: a TODO list.

Well, I think that it is not so big magic to understand what happens behind the
scenes, but I must admit that working without docs is very painful. I
experienced it in my new work, but that is another story and nothing to do with
PHP.

Colleen,

you said you stalled. Does it mean that you had used it some day with success?
If so, have you still got those sources to make a so called 'How-To'?

And a last question: what type of documentation would be the most useful?

- class reference (with property and method descriptions)
- tutorials
- how-tos

I know that all is needed, of course, but please make priorities.


Gyozo Papp

ErrorHandler TODO:

- session support and per-session debugging
(as set_error_handler now supports object callbacks it will be easier)

- documentation
(it's quite self-explanatory, we are lack of any good documentation now)

- tokenizer => revamped SOURCE report:
* opening and closing PHP tags
* new block mode (no need to parse with regexps)
* new highlight source with the use of CSS
? variable values in tooltips
=> affect on CONTEXT mode (finding variable variables)

- allow different 'step-in' error-levels
* per files and directories or even
* per programming elements(classes,objects,functions) using debug_backtrace
The meaning of 'step-in' is similar to the global LEVEL settings, but by
introducing this feature this setting can be varied from file to file, for
example. LEVEL directs ErrorHandler what type of errors to handle or to
ignore.
Several third-party packages presume the error_level .ini settings
excludeing E_NOTICE (E_ALL & ~E_NOTICE). Thus using them in an environment
where error_level is set to E_ALL, lots of annoying error messages are
thrown and presented to you, though you (including me) are commonly unlikely
to fix bugs in a 3rd party library. Then why brothering us with useless
error reports?

- assertion_failed() callback which handles errors fired by failed assertions.

- clarify any issue with assert()'s

- allow print_r() instead of built-in _sprint_var in CONTEXT report
(similar to var_export() )



Features from other sources
~~~~~~~~~~~~~~~~~~~~~~~~~~~
errorReporter from Dan Allen (www.mojavelinux.com/forum/viewtopic.php?t=51)
1. "exclude class" not only variables
(do not dump smarty, ADODB, etc.)
2. weep out repeated errors
(regarding to the PHP .ini settings responsible for the same thing)
3. customizable console window look'n feel (css)
4. click-on-bomb instead of automatically pop-up (choosable from .ini)

http://dev.izibox.isa-geek.org/NiceDebug/example.php
("David JL" <izi@...>)
1. CONTEXT report layout may be replaced with a floating windows on demand
3 layouts: raw, floating, [maybe embedded in SOURCE]??? -- I forgot it.


Questions
~~~~~~~~~
1. registering custom errorhandler would happen in constructor only,
not when including the script
2. there is an ini setting to ignore the repeated errors,
but does it affect custom error handling?
3. set() renamed to set_level() to lighten load_ini() and other methods


Upgrading to the latest PHP (4.3.0)
~~~~~~~~~~~~~~~~~~~~~~~~~~~
- revise ob functions neccessity
+ version_compare instead of phpversion
- array functions
- replace $HTTP_*_VARS with $_* superglobals
- debug_backtrace (there is a backport available for 4.2.0)
- possible use of new functions exchanging complex code blocks
- ready to use with session
+ set_error_handler supports object callback