ID:               38184
 User updated by:  shelby at coolpage dot com
 Reported By:      shelby at coolpage dot com
 Status:           Wont fix
 Bug Type:         Output Control
 Operating System: Irrelevant
 PHP Version:      4.4.2
 New Comment:

"...instead of spending your time with this monologue..."

So reporting bugs to you is a waste of our time?

We should stop reporting bugs?

100% nonsense.


Previous Comments:
------------------------------------------------------------------------

[2006-07-23 12:49:28] shelby at coolpage dot com

"...Why don't you just disable display_errors..."

How many times do I have to repeat what I already wrote, "...or it can
cause the reporting error to be not
reported...other than to turn off error reporting..."

The point is that this bug effectively causes error reporting to not
occur for JSON (or other Content-Types) output.  Whether that is
accomplished via corrupted output or via error_reporting( 0 ) is
besides the point.

The point being that without error reporting, users of the application
will get silent failure.  That is why error reporting exists in the
first place.  Error reporting is a fundamental aspect of robust
programming.

Your fix to a bug is mark it as "Won't Fix", tell the programmer to
turn off error reporting, and the accuse the bug reporter of typing a
"monologue"??

Wonderful.

------------------------------------------------------------------------

[2006-07-23 09:49:25] [EMAIL PROTECTED]

Why don't you just disable display_errors instead of spending your time
with this monologue?

------------------------------------------------------------------------

[2006-07-23 09:00:59] shelby at coolpage dot com

"...we prefer to get a nice error message instead..."

The nice error message ends up in corrupted output that the client does
not understand and thus can not display, thus that nice error is lost
and program can not be fixed, because user is unable to report the
error to programmers.

In short, the application just fails silently with a Javascript error
in the client.

I think you need to take some more time to understand the problem,
before jumping to "Won't Fix".

------------------------------------------------------------------------

[2006-07-23 08:52:50] shelby at coolpage dot com

"...we don't want the engine to crash..."

By the time the script has been terminated by an error, it logically
already has effectively crashed.  Each script runs in it's own process,
so if the engine crashes for a script while processing user error
reporting code, only that process of the engine crashes, thus
effectively this is the same as the script ending.  Thus my logic 101
applies.


"...NO catch/try blocks in 4.4.2..."

There are in PHP5.  Are we trying to go backwards or get a solution?


"...E_FATAL/E_ERROR errors are completely different from
exceptions..."

I repeat: "Even if we are talking about parsing errors (script is not
yet executing), why can't the set_handler_error input function be
parsed separately and run in a separate process?"


"...We would gladly review your patches..."

a) Then why is this bug marked "Won't Fix"?
b) Why not just say "don't report bugs to us that we don't want to hear
about"?
c) Miraculously "Won't Fix" bugs fall into a blackhole and are not
displayed on your stats page, so public is unaware of how many bugs you
won't fix:

http://bugs.php.net/bugstats.php

------------------------------------------------------------------------

[2006-07-23 07:59:09] [EMAIL PROTECTED]

>Then how do you explain the existence of catch{} recovery
> after try{} blocks?
First of all, there are NO catch/try blocks in 4.4.2 (and this is the
version you specified).
Second, try/catch block never did catch any errors at all, they are for
exceptions only.
Third, E_FATAL/E_ERROR errors are completely different from exceptions
and no wonder engines state is different too.

>Thus logic 101 says that #B is superior.
My logic says that we don't want the engine to crash and we prefer to
get a nice error message instead in case if your code is completely
wrong and is not going to work.

>Sounds to me the bug is something that you (the person
> changing this to "Won'd Fix") doesn't want to work on,
> versus being something impossible to fix?
We would gladly review your patches.

------------------------------------------------------------------------

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/38184

-- 
Edit this bug report at http://bugs.php.net/?id=38184&edit=1

Reply via email to