Hi Michaël,

first let me thank you to report this issue The situation is that
there will be (are ?) some new .ini directives which have not been
published yet and possibly missing from your ini file
([CONTEXT]/display and [LOGGING]/timestamp). I attach and upload, too,
the recent ini file structure.

When I started ErrorHandler my assumption was that all the ini
directives must be set in the ini files so to avoid the unneccessary
and annoying use of isset(). Though I think this requirement is
correct and the class works correctly in this case, it may be worth
rethinking.


Best regards,

Gyozo Papp

Michaël Willemot írta:

> Hey group,
>
> Just found out about the ErrorHandler class and tried version 2.0.0
(alpha 6) out.
>
> Well...when the popup-window comes up which shows me my errors...i still
> get error-warnings in my own page:
>
> Notice: Undefined index: display in /<snip>/ErrorHandler.php on line 534
>
> Notice: Undefined index: timestamp in /<snip>/scms/ErrorHandler.php on
> line 613
>
> Probably this can easily been fixed with using the isset() function
>
>
> Greetz,
>
>
>
>



; ErrorHandler configuration settings
; written by : Gyozo Papp @: gerzson@...
; VERSION-CTRL : 2.0.0
; last modified : 2003.02.28.
;
; This file is distributed as the part of the ErrorHandler package
under the
; licence terms and conditions presented in ErrorHandler informational
page
; (see readme.1st)


; -- IMPORTANT NOTE --
; Each following directive (except LOCKED, LEVEL and level's) must be
specified
; in a proper .ini file, that is, must not be commented out or left
out. Use
; the special value 'Off' or leave blank, if you don't want to supply
any value
; at all. (ErrorHandler has no default setting from now on.)
; This file contains each allowed configuration directive. The ones
commented
; out are not supported yet, e.g. SESSION.
; Comments (lines starting with can be removed at will apart from the
; authoring and licencing information above.

; -- GLOBAL settings --
;
; LOCKED controls if ini settings be protected from run-time changes
or not.
;
; If LOCKED is On, then no default ini directive can be changed by calling
; set_*() methods, though you can still twist ErrorHandler object
properties
; owing to the PHP's OO limitation (lack of private properties).
(However, I
; worked around it).
;
LOCKED = Off ; On/Off - run-time changes rejected/allowed, resp.


; general error reporting level is either an integer, or named constant.
; Using named constants is strongly encouraged
LEVEL = E_VERY_ALL


; You can specify a callback function which manipulates the original error
; messages. It may be handy if you want to print a precise error
message in the
; FAULT page (see below) and to hide some sensitive information as well.
; The supplied function must take 4 arguments: (see example in try.php)
; (string) message, (int) level, (string) file_name, (int) line_no
CUSTOM = ; the name of the callback function, e.g
'msg_customize'


; if SILENT is turned ON (or an error page is specified in REPLACE),
then the
; CONSOLE window will not be displayed, thus error reports can be
examined only
; where the log messages have been sent to. Another effect is similar
to the @
; operator: it suppresses error reporting from the point where it is
turned ON.
SILENT = Off ; whether CONSOLE window displayed or not


; MUTE directs ErrorHandler to treat errors muted by '@' error-suppressing
; operator as regular (Off) or not (On), that is, do nothing with
respect to
; the intended effect of '@'. By turning on, errors in expression
prepended
; with @ will not be reported at all, though it still can be trapped.
MUTE = Off


; TRAPCLEAR specifies if the error trap should be emptied
automatically after
; querying with is_trapped() method.
TRAPCLEAR = On


; Please note that SESSION is NOT SUPPORTED yet!!!
; The following lines only describes my conception about how to use
; ErrorHandler in conjuction with PHP sessions.
; ErrorHandler can register itself in the SESSION, so it can retains error
; messages/reports between redirections, i.e. after header('Location:
...');.
; A standalone terminal may fetch the error messages generated in the main
; script. It can be very helpful in a production environment where you can
; perform a per-session debugging. Now, ErrorHandler is not able to
distinguish
; one session from the rest, and so, there is no way to dedicate a session
; which error reports can be handled differently. In short, either each
; user can see the CONSOLE window at a certain page and each error message
; generated by each individual request will be logged or none of them.
; The per-session debugging is intended to break through this limitation.
;
;[SESSION]
; whether ErrorHandler is used with session or not
; already "figured out" directives:
;output = 'terminal' ; 'console', 'terminal'
;authorize= ; name of a callback function responsible for
; authenticate the session
;reset = ; whether restores ini definition after/before
script be
; executed

[REPLACE]
level = ;E_ERROR_ALL ; what type of error should halt the script
page = onerror.html ; the file to be displayed if script halts
redirect= ; whether the page displays immediately or try to
; redirect the browers
; acceptable values to 'redirect' are:
; On/Off - display immediately (old behaviour)
; server - force header('Location: ...');
; client - print javascript code into the HTML
source.
; Note that using 'client' disables CONSOLE window implicitly! It
seems odd
; first, but it is deliberated decision. If you want to redirect on
the client
; side, HTML content has already been sent to the client, because, for
example,
; something must be display (clock, progress bar, etc.) If so, CONSOLE
window
; could not be displayed, because output buffering is disabled
(content has been
; flushed already). If not, why not you use 'server'-side redirect
instead?
; It's still your responsibility to flush the content.
; However, do not trust on this feature too much! There may be so many
softwares
; on so many environments involved, that I hardly believe it will ever
work
; without twisting ErrorHandler source code. Read more about output
buffering in
; the PHP Manual (especially flush() and ob_implicit_flush(), etc)


[SOURCE]
level = E_NOTICE_NONE ; what type of error invokes CUSTOM handler
lines = 3 ; how many lines extracted around the failed line
block = On ; experimental -- NOT RECOMMENDED for general
use!!!
; 'lines' must be declared regardless to the actual value of 'block'. If
; ErrorHandler is not able to find the block where the error occurred,
it will
; print out that number of lines before and after the failed line.
; (old behaviour)
; 'block' has very limited capabilites now. Neither does it handle
alternative
; syntax nor recognize control structures spanning multiple lines,
such as:
; if ( /* conditions in the 1st line ...*/
; /* conditions in the 2nd line ...*/){ // block starts
here
; Comments and '}' inside string literals can fool ErrorHandler as well.


[CONTEXT]
strict = On ; variables in the extracted source be dumped only
depth = 5 ; how deep nested variables will be traversed
(at most)
exclude = HTTP_ENV_VARS HTTP_SERVER_VARS _ENV _SERVER pwd passwd password
; under no circumstances excluded variables
should be
; displayed
display = extended ; the preferred dumping format: var_export or
extended


[LOGGING]
; the directive can be one of the LOG target constant such as
FILE_LOG, MAIL_LOG
; and SYSTEM_LOG. The actual value of the directive is the log
destination.
; The user, under whose account the webserver is running (www-data,
nobody,
; wwwrun, etc), must have write permission to the logfile.
; See the following examples!
level = E_ALL
timestamp= [%x %X %Z] ; Timestamp format at the beginning of the
error messages
encrypt = Off ; the name of the callback function to encrypt
; logmail message
collect = On ; collect error reports and send one mail per
request
; (using register_shutdown_function(), see PHP
Manual!)
FILE_LOG = /tmp/ErrorHandler.log
MAIL_LOG = your@...
SYSTEM_LOG = Off


; ALTDLOG -- Auto logging target detection
; You can specify additional log destinations to a specific file with
ALTDLOG.
; If an error occurs in a registered file, ErrorHandler sends a log
message to
; the specified location (it can either a file or a mail box, just
like LOGGING)
; (Please note that the LOGGING/encrypt setting affects ALTDLOG mails,
too.)
; The section name is the name of the file to be registered, it must
exists in
; the local file system. Allowed directives are the same as in LOGGING.
;
; The following sections are examples for ALTDLOG file registering
;
[ErrorHandler.inc]
level = E_VERY_ALL
MAIL_LOG = gerzson@...

[/path/to/your/file.php]
FILE_LOG = file.log
MAIL_LOG = mail@...