Re: [PHP] Fatal Errors and Error Handling
Christian Reiniger [EMAIL PROTECTED] wrote in message
01042417490700.07614@chrisbig">news:01042417490700.07614@chrisbig...
Well, needed to use might be incorrect, because return value evaluation
can be used instead (unless some functions never signal errors via their
return value). Aside from that you're right.
OK, I will try to clarify my original problem...
At http://www.php.net/manual/en/function.xslt-process.php there is an
example program. When I use it as is, it works all right and produces a nice
table. Here is a short section of the code:
-
[...]
if (xslt_process($xslData, $xmlData, $result)) {
[...]
} else {
echo There was an error that occurred in the XSL transformation...\n;
echo \tError number: . xslt_errno() . \n;
echo \tError string: . xslt_error() . \n;
exit;
}
?
-
This is quite similar to what I am trying. If you now corrupts the xmlData
variable, e.g. by changing article to rticl without changing the closing
tag, you will get an error message saying
br
bFatal error/b: XML parser error 7: mismatched tag in
b/var/www/test.php/b on line b40/bbr
As you can see here, xslt_process() dies with a fatal error and the program
is terminated, and we never get to testing the return value. The next
problem, is that since the error is fatal, it is also not possible to use
set_error_handler() to catch the error. And placing the @-sing before the
variable only supresses the default error-message, which is not an
acceptable solution to us. The last thing I tried, was the
error_prepend_string and error_append_string in php.ini, but it is very
difficult making a valid error-message this way. Because of the unclosed
br tags we don't get a valid xml-message. And because of the b and br
tags, it would not comply with the error-message format we need to use
anyway. And using the @-sing causes error_append/prepend_string to be
ignored alltogether.
And in my opinion, there are too many things that can cause PHP to die with
a fatal error. So we simply *must* be able to handle it and give a valid and
reasonable error-message back.
--
Svein Roar Nilsen
Norwegian Hydrographic Services
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Fatal Errors and Error Handling
On Wednesday 25 April 2001 13:32, Svein Roar Nilsen wrote: [...] This is quite similar to what I am trying. If you now corrupts the xmlData variable, e.g. by changing article to rticl without changing the closing tag, you will get an error message saying br bFatal error/b: XML parser error 7: mismatched tag in b/var/www/test.php/b on line b40/bbr As you can see here, xslt_process() dies with a fatal error and the program is terminated, and we never get to testing the return value. [] And in my opinion, there are too many things that can cause PHP to die with a fatal error. So we simply *must* be able to handle it and give a valid and reasonable error-message back. Ok, agreed. I'd consider this a bug that should be submitted to bugs.php.net It's certainly not acceptable that code using xslt_process() has *no way* of recovering from a (quite common) error. Corrupted data is something to be expected, something that even has to be considered *normal* when developing such a thing. -- Christian Reiniger LGDC Webmaster (http://sunsite.dk/lgdc/) Software is like sex: the best is for free -- Linus Torvalds -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Fatal Errors and Error Handling
And I see no reason why we should not be allowed to handle most of the fatal errors we get on our own. Especially annoying is the xslt_process() function that returns something like brbFatal error/b: XML parser error 7: mismatched tag in b/var/www/[...]. As far as I can see, this http://www.php.net/manual/en/features.error-handling.php have you taken a deeper look into this? Well, I have tried... beside, use @ in front of the command to pipe away the current error or stop on-screen display of errors in general. My problem is that not displaying anything in case of an error is a completely unacceptable solution. I *MUST* return a valid XML message in a predefined format. If not, I am violating the standard we are following. And if I do not find a way to comply with the standard, it means that we have to scrap PHP alltogether for this project. Svein Roar -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Fatal Errors and Error Handling
http://www.php.net/manual/en/features.error-handling.php have you taken a deeper look into this? Well, I have tried... And what kind of problem did you encounter? My problem is that not displaying anything in case of an error is a completely unacceptable solution. I *MUST* return a valid XML message in a predefined format. If not, I am violating the standard we are but that, as far as I've understand your case, isn't a problem. -- php developer / CoreTrek AS| Recent investments will yield a slight Sandnes / Rogaland / Norway| profit. web: http://www.moijk.net/ | -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Fatal Errors and Error Handling
On Tuesday 24 April 2001 12:14, Svein Roar Nilsen wrote:
beside, use @ in front of the command to pipe away the current error
or stop on-screen display of errors in general.
My problem is that not displaying anything in case of an error is a
completely unacceptable solution. I *MUST* return a valid XML message
in a predefined format. If not, I am violating the standard we are
if (@foo_bar (42, 4711) == ERROR_CODE) {
PrintXMLErrorMessage ();
}
else {
GoOnProcessing ();
}
--
Christian Reiniger
LGDC Webmaster (http://sunsite.dk/lgdc/)
...1000100011010101101010110100111010113...
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Fatal Errors and Error Handling
Geir Eivind Mork wrote: http://www.php.net/manual/en/features.error-handling.php have you taken a deeper look into this? Well, I have tried... And what kind of problem did you encounter? The problem is that PHP generates fatal errors too often, and I have not been able to find a way of trapping them. It also means that I am not able to generate an error-message of the requiered form, e.g. something like ?xml version=1.0 encoding=UTF-8 ? my_reply my_error Internal server error /my_error /my_reply What I do not need, is something like brbFatal error/b: XML parser error 7: mismatched tag in b/var/www/[...] And returning nothing would be even worse. The messages are meant to be machine-readable, meaning we must comply with the standards. but that, as far as I've understand your case, isn't a problem. Yes, it is. Because many functions generate fatal errors instead of simply returning false or generating a warning. I have tried using the set_error_handler(), but it only traps warnings and notices. It is possible that I am doing something wrong, so if you can give me a short working example, I should be really grateful! Svein Roar -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Fatal Errors and Error Handling
My problem is that not displaying anything in case of an error is a
completely unacceptable solution. I *MUST* return a valid
XML message in a predefined format. If not, I am violating the
standard we are
if (@foo_bar (42, 4711) == ERROR_CODE) {
PrintXMLErrorMessage ();
I do not believe the above will work. When using the @ symbol
in front of an expression, it makes it so that the error code that is
returned is 0. While writing my error handler class, in the
function that processes whatever error is triggered, I check to see
if the error code is 0 and if it is, I do nothing because there was
an @ symbol prepended to the expression.
You can read more about this in the error handling section of the
documentation.
Chris
Re: [PHP] Fatal Errors and Error Handling
On Tuesday 24 April 2001 14:47, Boget, Chris wrote:
My problem is that not displaying anything in case of an error is a
completely unacceptable solution. I *MUST* return a valid
XML message in a predefined format. If not, I am violating the
standard we are
if (@foo_bar (42, 4711) == ERROR_CODE) {
PrintXMLErrorMessage ();
I do not believe the above will work. When using the @ symbol
in front of an expression, it makes it so that the error code that is
returned is 0. While writing my error handler class, in the
Wrong. From http://php.net/manual/en/language.operators.errorcontrol.php :
--
PHP supports one error control operator: the at sign (@). When prepended
to an expression in PHP, any error messages that might be generated by
that expression will be ignored.
--
The @ operator suppresses any error *message*, but leaves the return
value intact.
Just imagine that with your interpretation in the following snippet
$conn = @mysql_connect(...)
$conn would always be set to 0...
--
Christian Reiniger
LGDC Webmaster (http://sunsite.dk/lgdc/)
I sat laughing snidely into my notebook until they showed me a PC running
Linux. And oh! It was as though the heavens opened and God handed down a
client-side OS so beautiful, so graceful, and so elegant that a million
Microsoft developers couldn't have invented it even if they had a hundred
years and a thousand crates of Jolt cola.
- LAN Times
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Fatal Errors and Error Handling
standard we are
if (@foo_bar (42, 4711) == ERROR_CODE) {
PrintXMLErrorMessage ();
I do not believe the above will work. When using the @ symbol
in front of an expression, it makes it so that the error
code that is returned is 0. While writing my error handler class,
in the
Wrong. From
http://php.net/manual/en/language.operators.errorcontrol.php :
--
PHP supports one error control operator: the at sign (@). When prepended
to an expression in PHP, any error messages that might be generated by
that expression will be ignored.
--
The @ operator suppresses any error *message*, but leaves the return
value intact. Just imagine that with your interpretation in the following
snippet
$conn = @mysql_connect(...)
$conn would always be set to 0...
Wrong back. From:
http://php.net/manual/en/function.set-error-handler.php
It is important to remember that the standard PHP error handler is
completely bypassed. error_reporting() settings will have no effect
and your error handler will be called regardless - however you are
still able to read the current value of error_reporting() and act
appropriately. Of particular note is that this value will be 0 if the
statement that caused the error was prepended by the @ error-control
operator.
Using your example, $conn wouldn't be '0' but if any error that is
generated by mysql_connect, that error code/number (what you are
going to be looking for) will be '0'. So if, in the original function
f00_bar(), it tried to return any error code/number, that code/number
would be '0' (zero) by nature of having the @ operator prepended
to the function call.
You don't have to believe me. Set up your own error handler and
see for yourself what error number you get when the @ symbol
is prepended to an expression.
Chris
Re: [PHP] Fatal Errors and Error Handling
On Tuesday 24 April 2001 16:48, Boget, Chris wrote:
standard we are
if (@foo_bar (42, 4711) == ERROR_CODE) {
PrintXMLErrorMessage ();
Wrong back. From:
http://php.net/manual/en/function.set-error-handler.php
It is important to remember that the standard PHP error handler is
completely bypassed. error_reporting() settings will have no effect
and your error handler will be called regardless - however you are
still able to read the current value of error_reporting() and act
appropriately. Of particular note is that this value will be 0 if the
statement that caused the error was prepended by the @ error-control
operator.
Using your example, $conn wouldn't be '0' but if any error that is
generated by mysql_connect, that error code/number (what you are
going to be looking for) will be '0'. So if, in the original function
f00_bar(), it tried to return any error code/number, that code/number
would be '0' (zero) by nature of having the @ operator prepended
to the function call.
Well, we both are right. The snippet I suggested (top of this mail)
*will* work, because the @ operator doesn't mess with the return value of
the function. A custom error handling function installed via
set_error_handler() will *not* work because it won't get the error code.
But I never suggested using set_error_handler() :)
--
Christian Reiniger
LGDC Webmaster (http://sunsite.dk/lgdc/)
I sat laughing snidely into my notebook until they showed me a PC running
Linux. And oh! It was as though the heavens opened and God handed down a
client-side OS so beautiful, so graceful, and so elegant that a million
Microsoft developers couldn't have invented it even if they had a hundred
years and a thousand crates of Jolt cola.
- LAN Times
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Fatal Errors and Error Handling
if (@foo_bar (42, 4711) == ERROR_CODE) {
PrintXMLErrorMessage ();
Well, we both are right. The snippet I suggested (top of this mail)
*will* work, because the @ operator doesn't mess with the return
value of the function.
That is correct. However, the == ERROR_CODE suggests that
an error code will be returned by foo_bar(). However, that code
will be suppressed by the @ symbol and that is what I was commenting
on... the fact that the above example couldn't be used if you wanted
to print your own error messsage.
A custom error handling function installed via set_error_handler()
will *not* work because it won't get the error code.
Well, it will work and it will still be called. However, the error code
passed to it will be '0'.
But I never suggested using set_error_handler() :)
But the issue at hand was the fact that the original poster
was using, and needed to use, set_error_handler to handle
their own errors.
Chris
Re: [PHP] Fatal Errors and Error Handling
On Tuesday 24 April 2001 17:14, Boget, Chris wrote:
if (@foo_bar (42, 4711) == ERROR_CODE) {
PrintXMLErrorMessage ();
Well, we both are right. The snippet I suggested (top of this mail)
*will* work, because the @ operator doesn't mess with the return
value of the function.
That is correct. However, the == ERROR_CODE suggests that
an error code will be returned by foo_bar(). However, that code
will be suppressed by the @ symbol and that is what I was commenting
on... the fact that the above example couldn't be used if you wanted
to print your own error messsage.
Functions return some value. Depending on the function, some ranges of
returned values are interpreted as error code (e.g. 0 for mysql_connect).
That is *not* in any way suppressed by @.
But I never suggested using set_error_handler() :)
But the issue at hand was the fact that the original poster
was using, and needed to use, set_error_handler to handle
their own errors.
Well, needed to use might be incorrect, because return value evaluation
can be used instead (unless some functions never signal errors via their
return value). Aside from that you're right.
--
Christian Reiniger
LGDC Webmaster (http://sunsite.dk/lgdc/)
I sat laughing snidely into my notebook until they showed me a PC running
Linux. And oh! It was as though the heavens opened and God handed down a
client-side OS so beautiful, so graceful, and so elegant that a million
Microsoft developers couldn't have invented it even if they had a hundred
years and a thousand crates of Jolt cola.
- LAN Times
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Fatal Errors and Error Handling
On Monday 23 April 2001 17:29, Svein Roar Nilsen wrote: And I see no reason why we should not be allowed to handle most of the fatal errors we get on our own. Especially annoying is the xslt_process() function that returns something like brbFatal error/b: XML parser error 7: mismatched tag in b/var/www/[...]. As far as I can see, this http://www.php.net/manual/en/features.error-handling.php have you taken a deeper look into this? beside, use @ in front of the command to pipe away the current error or stop on-screen display of errors in general. -- php developer / CoreTrek AS| Only God can make random selections. Sandnes / Rogaland / Norway| web: http://www.moijk.net/ | -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
