Comments on: Beyond Error Logs

By: Matthew Purdon

Matthew Purdon — Mon, 22 Dec 2008 16:21:38 +0000

@Brandon Savage: I completely agree that in production your code should not have any warnings or notices (I always run Strict reporting anyway) But the point of this debug console is not to “log” things, but more to give you insight into what the application is doing. For example, 10 of us work on our little parts and we each do two db queries. It seems like we are writing good code, but when taken together we see in the firebug console that we are actually running 20 queries to build the page. Not cool. Firebug gives us insight into what our app is doing as a whole, in real time. As for logging errors, I don’t know anyone that writes all of their code perfectly on the first attempt. I personally hate having to go in and disable images or view source to try to find the error message or try to pretty-print it. With Firebug you get to easily see the error and the stack trace in a pretty little window.
@Lucas: I totally agree that the building of messages in the console is annoying. There should be an option in FireBug to reset after each request. *shrug*
@AppBeacon: Absolutely, we have a DEBUG=true flag in our dev config and it’s false in the production config. The nice part about the way I did it is that the Firebug writer isn’t even loaded in Production, so it’s very unlikely that you will be sending secret infos to the browser in production.

By: AppBeacon

AppBeacon — Fri, 19 Dec 2008 19:19:22 +0000

FirePHP is a great tool. The developer, Christoph Dorn, is very easy to communicate with and fixes any bugs pretty quickly.
I would just point out that you must be very careful about preventing output to FirePHP when you deploy the final product. Imagine the fun people could have with your site if you exposed the underlying database info via a query that was sent to the console.

By: Brian DeShong

Brian DeShong — Wed, 17 Dec 2008 22:09:25 +0000

On a related note, I plan to craft up a Zend_Cache_Profiler proposal very soon that will allow for out-of-the-box Memcached logging to FirePHP, just like Zend_Db_Profiler_Firebug.
We’ve built something similar for another Schematic project, so I’m making it a point to propose these things up as Zend Framework proposals.
Three cheers for ZF and its CLA!

By: Lukas

Lukas — Wed, 17 Dec 2008 20:34:01 +0000

We have something similar in our system and we are quite happy with it. We dont log quite as much information though. By default I only log some basics along with failed queries. I will probably add at least some information about how many queries were executed for a total of how long. In debug mode we log a lot more.
This is all fine and dandy, but I see two annoyances at this point:
1) if you do not look at your console for a while, on the next glimpse you will see pages of debug content fly up as the display picks up of all the message you did not look at yet
2) no firephp on MSIE .. well there is firebug-lite and i guess with a bit of hackery, one could define a hidden place in the DOM/JSON response that could then be picked up by a firephp-lite and passed to firebug-lite ..

By: Brandon Savage

Brandon Savage — Wed, 17 Dec 2008 17:39:51 +0000

For me, any application that emits any sort of error message is broken. All errors – including notices – should be gone before code is released. It’s one thing if your app logs warnings and notices due to some actual failure, but it’s just bad coding if you accept warnings and notices as “standard.”