Pox was designed so that logging and profiling was easy and easily provided different options.

We maintain use of the PEAR Logger underneath.

Zend_Registry::get('logger')->debug("This is my debug message");

You can use debug()or any other log levels supported by the logger.

Currently, by default, the logger will log to a file on disk in artifacts/logs/out.logany message at INFOlevel or higher, i.e. everything but DEBUGmessages. You can include this DEBUGmessage in one of two ways:

1. change the setting in config/config.ini

application.debug.enabled = true 

1. include the debugGET parameter in the query string:

http://localhost/blogs?debug=1 

You can log to two additional destinations by doing one or more of the following:

1. include the log_window GET parameter in the query string:

http://localhost/blogs?log_window=1 

A browser popup window will appear with logging statements.

1. include the log_file GET parameter specifying a filename in the query string:

http://localhost/blogs?log_file=my_log.log 

The file in artifacts/logs/my_log.log will contain logging for that request.

You can mix and match the above parameters, for example:

http://localhost/blogs?debug=1&log_window=1&log_file=my_log.log 

You can create an xdebug execution trace by including a xdebug_traceGET param in the query string, specifying a filename:

http://localhost/blogs?xdebug_trace=my_trace.xt 

The file in artifacts/logs/my_trace.xt will contain the trace.

Profiling works similar to logging. To profile a section of code, include this line at the beginning and end of the section you want to profile.

Zend_Registry::get('logger')->profile(__METHOD__, __FILE__, __LINE__); 

Then, include the profileGET param to the query string, and a popup window will log the elapse time between each profile()call.

http://localhost/blogs?profile=1 

All PHP errors (except Fatal Errors, but including Warnings, Notices, etc.) are converted into Exceptions and thrown. What this means is that all error handling is done via exceptions. All exceptions must be handled in a try/catch block, or else, if exception is not handled and makes its way all the way to the top of the call stack, a PHP Fatal Error will be raised. In production mode, an uncaught Exception will result in an error page with an encoded stack dump suitable for emailing.

This is handled by the Errors class.