NAME
Catalyst::Manual::Tutorial::Debugging - Catalyst Tutorial - Part 6: Debugging
OVERVIEW
This is Part 6 of 9 for the Catalyst tutorial.
Debugging
DESCRIPTION
This part of the tutorial takes a brief look at the primary options available for troubleshooting Catalyst applications.
Note that when it comes to debugging and troubleshooting, there are two camps:
Fans of
log
andprint
statements embedded in the code.Fans of interactive debuggers.
Catalyst is able to easily accommodate both styles of debugging.
LOG STATEMENTS
Folks in the former group can use Catalyst's $c->log
facility. (See Catalyst::Log for more detail.) For example, if you add the following code to a controller action method:
$c->log->info("Starting the foreach loop here");
$c->log->debug("Value of $id is: ".$id);
Then the Catalyst development server will display your message along with the other debug output. To accomplish the same thing in a TTSite view use:
[% Catalyst.log.debug("This is a test log message") %]
You can also use Data::Dumper in both Catalyst code (use Data::Dumper; $c->log->debug("$var is: ".Dumper($var));)
) and TT templates ([% Dumper.dump(book) %]
.
RUNNING CATALYST UNDER THE PERL DEBUGGER
Members of the interactive-debugger fan club will also be at home with Catalyst applications. One approach to this style of Perl debugging is to embed breakpoints in your code. For example, open lib/MyApp/Controller/Books.pm
in your editor and add the DB::single=1
line as follows inside the list
method (I like to "left-justify" my debug statements so I don't forget to remove them, but you can obviously indent them if you prefer):
sub list : Local {
# Retrieve the usual perl OO '$self' for this object. $c is the Catalyst
# 'Context' that's used to 'glue together' the various components
# that make up the application
my ($self, $c) = @_;
$DB::single=1;
# Retrieve all of the book records as book model objects and store in the
# stash where they can be accessed by the TT template
$c->stash->{books} = [$c->model('MyAppDB::Book')->all];
# Set the TT template to use. You will almost always want to do this
# in your action methods.
$c->stash->{template} = 'books/list.tt2';
}
This causes the Perl Debugger to enter "single step mode" when this command is encountered (it has no effect when Perl is run without the -d
flag).
To now run the Catalyst development server under the Perl debugger, simply prepend perl -d
to the front of script/myapp_server.pl
:
$ perl -d script/myapp_server.pl
This will start the interactive debugger and produce output similar to:
$ perl -d script/myapp_server.pl
Loading DB routines from perl5db.pl version 1.27
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(script/myapp_server.pl:14): my $debug = 0;
DB<1>
Press the c
key and hit Enter
to continue executing the Catalyst development server under the debugger. Although execution speed will be slightly slower than normal, you should soon see the usual Catalyst startup debug information.
Now point your browser to http://localhost:3000/books/list and log in. Once the breakpoint is encountered in the MyApp::Controller::list
method, the console session running the development server will drop to the Perl debugger prompt:
MyApp::Controller::Books::list(/home/me/MyApp/script/../lib/MyApp/Controller/Books.pm:40):
40: $c->stash->{books} = [$c->model('MyAppDB::Book')->all];
DB<1>
You now have the full Perl debugger at your disposal. First use the next
feature by typing n
to execute the all
method on the Book model (n
jumps over method/subroutine calls; you can also use s
to single-step
into methods/subroutines):
DB<1> n
SELECT me.id, me.authors, me.title, me.rating FROM books me:
MyApp::Controller::Books::list(/home/me/MyApp/script/../lib/MyApp/Controller/Books.pm:44):
44: $c->stash->{template} = 'books/list.tt2';
DB<1>
This takes you to the next line of code where the template name is set. Notice that because we enabled DBIC_TRACE=1
earlier, SQL debug output also shows up in the development server debug information.
Next, list the methods available on our Book
model:
DB<1> m $c->model('MyAppDB::Book')
()
(0+
(bool
MODIFY_CODE_ATTRIBUTES
_attr_cache
_collapse_result
_construct_object
_count
_result_class_accessor
_result_source_accessor
all
carp
<lines removed for brevity>
DB<2>
We can also play with the model directly:
DB<2> x ($c->model('MyAppDB::Book')->all)[1]->title
SELECT me.id, me.title, me.rating FROM books me:
0 'TCP/IP Illustrated, Volume 1'
This uses the Perl debugger x
command to display the title of a book.
Next we inspect the books
element of the Catalyst stash
(the 4
argument to the x
command limits the depth of the dump to 4 levels):
DB<3> x 4 $c->stash->{books}
0 ARRAY(0xa8f3b7c)
0 MyApp::Model::MyAppDB::Book=HASH(0xb8e702c)
'_column_data' => HASH(0xb8e5e2c)
'id' => 1
'rating' => 5
'title' => 'CCSP SNRS Exam Certification Guide'
'_in_storage' => 1
<lines removed for brevity>
Then enter the c
command to continue processing until the next breakpoint is hit (or the application exits):
DB<4> c
SELECT author.id, author.first_name, author.last_name FROM ...
Finally, press Ctrl+C
to break out of the development server. Because we are running inside the Perl debugger, you will drop to the debugger prompt. Press q
to exit the debugger and return to your OS shell prompt:
DB<4> q
$
For more information on using the Perl debugger, please see perldebug
and perldebtut
. You can also type h
or h h
at the debugger prompt to view the built-in help screens.
DEBUGGING MODULES FROM CPAN
Although the techniques discussed above work well for code you are writing, what if you want to use print/log/warn messages or set breakpoints in code that you have installed from CPAN (or in module that ship with Perl)? One helpful approach is to place a copy of the module inside the lib
directory of your Catalyst project. When Catalyst loads, it will load from inside your lib
directory first, only turning to the global modules if a local copy cannot be found. You can then make modifications such as adding a $DB::single=1
to the local copy of the module without risking the copy in the original location. This can also be a great way to "locally override" bugs in modules while you wait for a fix on CPAN.
Matt Trout has suggested the following shortcut to create a local copy of an installed module:
mkdir -p lib/Module; cp `perldoc -l Module::Name` lib/Module/
For example, you could make a copy of Catalyst::Plugin::Authentication with the following command:
mkdir -p lib/Catalyst/Plugin; cp \
`perldoc -l Catalyst::Plugin::Authentication` lib/Catalyst/Plugin
Note: Matt has also suggested the following tips for Perl debugging:
Check the version of an installed module:
perl -MModule::Name -e 'print $Module::Name::VERSION;'
For example:
$ perl -MCatalyst::Plugin::Authentication -e \ 'print $Catalyst::Plugin::Authentication::VERSION;' 0.07
Check if a modules contains a given method:
perl -MModule::Name -e 'print Module::Name->can("method");'
For example:
$ perl -MCatalyst::Plugin::Authentication -e \ 'print Catalyst::Plugin::Authentication->can("prepare");' CODE(0x9c8db2c)
If the method exists, the Perl
can
method returns a coderef. Otherwise, it returns undef and nothing will be printed.
AUTHOR
Kennedy Clark, hkclark@gmail.com
Please report any errors, issues or suggestions to the author. The most recent version of the Catalyst Tutorial can be found at http://dev.catalyst.perl.org/repos/Catalyst/trunk/Catalyst-Runtime/lib/Catalyst/Manual/Tutorial/.
Copyright 2006, Kennedy Clark, under Creative Commons License (http://creativecommons.org/licenses/by-nc-sa/2.5/).