php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #23826 ob_end_clean() returns error notice when buffer is empty
Submitted: 2003-05-27 01:21 UTC Modified: 2003-05-27 19:24 UTC
From: jc at mega-bucks dot co dot jp Assigned: helly (profile)
Status: Closed Package: Documentation problem
PHP Version: 4.3.2RC4 OS: Red Hat Linux 8.0
Private report: No CVE-ID: None
 [2003-05-27 01:21 UTC] jc at mega-bucks dot co dot jp
I get the following notice/error when calling ob_end_clean()

Notice: ob_end_clean(): failed to delete buffer. No buffer to delete. 

#1 - why is it an error to call ob_end_clean() on an empty output buffer?
#2 - Must one check before hand if the output buffer has any content, if so the documentation should state this.

Thanks!

PS I am using PHP 4.3.2RC3

Patches

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-05-27 02:17 UTC] sniper@php.net
The notice was added to prevent it from crashing with empty buffers. Just use @ in front of it if it bothers you.
Docs should mention this though.


 [2003-05-27 02:23 UTC] jc at mega-bucks dot co dot jp
>The notice was added to prevent it from crashing with empty buffers

I must be missing something ... how does throwing a notice prevent anything from crashing? Or do you mean there is absolutely no way to check that the output buffer is empty *except* to call ob_end_clean() and check to see if a notice was thrown or not?

If that's the case then ... ouch.

>Docs should mention this though.

That would be nice ;) Does re-categorizing it as a documentation problem mean that someone will get around to it or should I submit a new documentation bug report?

Thanks!
 [2003-05-27 03:10 UTC] sniper@php.net
You don't need to submit anymore bug reports..

And I meant with that crash preventing that it now throws
an error and returns false, reviously when it didn't check
the buffer, it just crashed. (that was the fix)


 [2003-05-27 03:19 UTC] 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 ;)
 [2003-05-27 10:12 UTC] goba@php.net
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 13:25 UTC] helly@php.net
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 18:48 UTC] 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 18:52 UTC] 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 19:24 UTC] sniper@php.net
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.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Aug 18 10:01:29 2024 UTC