ID: 23826 Updated by: [EMAIL PROTECTED] Reported By: jc at mega-bucks dot co dot jp -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Red Hat Linux 8.0 PHP Version: 4.3.2RC4 Assigned To: helly New Comment:
This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: ------------------------------------------------------------------------ [2003-05-27 18:52:51] jc at mega-bucks dot co dot jp helly: even if it is decided that the notice is valid, the documentation still needs to be updated to state this. ------------------------------------------------------------------------ [2003-05-27 18:48:48] jc at mega-bucks dot co dot jp I totally understand your point of view. It's just that in my opinion if an E_NOTICE is generated then it probably means there is something wrong with my code [1]. If there is nothing wrong with calling ob_end_clean() on an empty buffer, then why have it generate a notice? Using @ would get rid of the notice, but if I understand the documentation correctly for the use of @ then I won't catch any *real* errors messages, they'll just be ignored [2]. So basically my question/problem comes down to this. Why is ob_end_clean() generating a notice? It's generating a notice to tell you that you call the function on an empty output buffer. Why is it bothering telling me this? It's bothering to tell me because either a) this is wrong and I shouldn't be doing it or b) it's being friendly and thinks it should let me know that I did something that I probably didn't intend to do. So is it case A (an error) or case B (possible poor programming). If it's case A then an ERROR should be generated, not a notice. If it's case B then #1- I can understand the logic being a notice for an uninitialized variable, but the output buffer is something generated by PHP in the backgroud, so it's not like I am trying to use something I didn't initialize ... #2- there should be a way for me to prevent the generation of "possible sloppy programming" friendly notices by checking beforehand that the buffer is not empty if it is deemed that this friendly notice is valid. And the prevention of these notices shold not interfere with the generation of *real* ERROR messages ... Just my 2 cents ;) [1] http://jp.php.net/manual/en/language.operators.errorcontrol.php Currently the "@" error-control operator prefix will even disable error reporting for critical errors that will terminate script execution. Among other things, this means that if you use "@" to suppress errors from a certain function and either it isn't available or has been mistyped, the script will die right there with no indication as to why. [2] http://jp.php.net/manual/en/ref.errorfunc.php NOTICE messages will warn you about possibls bugs in your code. [...] Run-time notices. Indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script. ------------------------------------------------------------------------ [2003-05-27 13:25:16] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php 1) It is a notice and not an error 2) this notice tells you: you are doing unnecessary stuff 3) to clear all buffers do: while(@ob_end_clean()); ------------------------------------------------------------------------ [2003-05-27 10:12:58] [EMAIL PROTECTED] Why do you want to check before calling ob_end_clean()? It seems you simply want to call that then why not @ob_end_clean()? ------------------------------------------------------------------------ [2003-05-27 03:19:41] jc at mega-bucks dot co dot jp Ok. I understand the "bug fix" but that fix now causes another problem ... I have a custom error handler with the following code: $buffer = ob_get_contents(); ob_end_clean(); The call to ob_end_clean() will throw a notice if the buffer if empty, which will cause the error handler to either fail or call itself again (possibly infinitely?). So just to be clear, it seems you are saying that *technically* calling ob_end_clean() on an empty buffer is incorrect? If this is so, what is the proprer way of checking if the buffer is empty before calling ob_end_clean()? If there is a way of checking wether the buffer is empty or not then all is fine, if not then there is a problem ;) ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/23826 -- Edit this bug report at http://bugs.php.net/?id=23826&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
