In the past, many softwares have used an error handler function to
provide the following cases:
1. Log the error in a more complicated way than PHP does by default.
2. Send off an email, if necessary, or communicate with another service.
3. Show a generic (e.g. a 500) error message to the client.
Now, if I have display_errors set to 0, and my code calls a function
that does not exist, or a property it doesn't have access to, the user
will see a blank screen (or whatever has been outputted thus far.)
Obviously any such egregious errors should have been caught before the,
let's say, build got to the beta tester or end client... but by the same
logic segfaults should never be found in production C code either.
Guess that never happens too, right?
In fact, the example on the ref.errorfunc.php doc page shows exactly the
sort of thing that is not possible for these types of errors now.
Simple error logging seems to fall apart, though, because when your
software is on a box you have no control over... and an end user gets an
error the end client doesn't even know about, you typically never find
out. Even if the end client has opted to send you any errors that happen.
-[Unknown]
-------- Original Message --------
On 10-Aug-06, at 9:35 AM, Michael Walter wrote:
What do you feel is incorrect about allowing mentioned errors to be
handled in userspace?
My feeling is that errors such as visibility violations should be
addressed during debugging and Q&A phase where simple error logging will
be sufficient to track them.
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
