view release on metacpan or  search on metacpan

lib/Dancer2/Plugin/LogReport.pod  view on Meta::CPAN

  get 'route' => sub {
      my $foo = 1;
      my $bar = $foo->{x}; # whoops
  }

For a production application (C<show_errors: 1>), the message saved in the
session will be the generic text "An unexpected error has occurred". This
can be customised in the configuration file, and will be translated.

=head3 Sending messages to the user

To make it easier to send messages to your users, messages at the following
levels are also stored in the user's session: C<notice>, C<warning>, C<mistake>,
C<error>, C<fault>, C<alert>, C<failure> and C<panic>.

You can pass these to your template and display them at each page render:

  hook before_template => sub {
    my $tokens = shift;
    $tokens->{messages} = session 'messages';
    session 'messages' => []; # Clear the message queue
  }

Then in your template (for example the main layout):

  [% FOR message IN messages %]
    <div class="alert alert-[% message.bootstrap_color %]">
      [% message.toString | html_entity %]
    </div>
  [% END %]

The C<bootstrap_color> of the message is compatible with Bootstrap contextual
colors: C<success>, C<info>, C<warning> or C<danger>.

When you use L<Dancer2::Template::TTLogReport|Dancer2::Template::TTLogReport> as well, which enables the
translations of your whole templates, then add C<locale>:

  [% message.toString(locale) | html_entity %]

Now, anywhere in your application that you have used L<Log::Report|Log::Report>, you can

  warning "Hey user, you should now about this";

and the message will be sent to the next page the user sees.

=head3 Handling user errors

Sometimes we write a function in a model, and it would be nice to have a
nice easy way to return from the function with an error message. One
way of doing this is with a separate error message variable, but that
can be messy code. An alternative is to use exceptions, but these
can be a pain to deal with in terms of catching them.
Here's how to do it with L<Log::Report|Log::Report>.

In this example, we do use exceptions, but in a neat, easier to use manner.

First, your module/model:

  package MyApp::CD;

  sub update {
    my ($self, %values) = @_;
    $values{title} or error "Please enter a title";
    $values{description} or warning "No description entered";
  }

Then, in your controller:

  package MyApp;
  use Dancer2;

  post '/cd' => sub {
    my %values = (
      title       => param('title');
      description => param('description');
    );
    if (process sub { MyApp::CD->update(%values) } ) {
      success "CD updated successfully";
      redirect '/cd';
    }

    template 'cd' => { values => \%values };
  }

Now, when update() is called, any exceptions are caught. However, there is
no need to worry about any error messages. Both the error and warning
messages in the above code will have been stored in the messages session
variable, where they can be displayed using the code in the previous section.
The C<error> will have caused the code to stop running, and process()
will have returned C<false>. C<warning> will have simply logged the warning
and not caused the function to stop running.

=head3 Logging DBIC database queries and errors

If you use L<DBIx::Class> in your application, you can easily integrate
its logging and exceptions. To log SQL queries:

  # Log all queries and execution time
  $schema->storage->debugobj(new Log::Report::DBIC::Profiler);
  $schema->storage->debug(1);

By default, exceptions from DBIC are classified at the level "error". This
is normally a user level error, and thus may be filtered as normal program
operation. If you do not expect to receive any DBIC exceptions, then it
is better to class them at the level "panic":

  # panic() DBIC errors
  $schema->exception_action(sub { panic @_ });
  # Optionally get a stracktrace too
  $schema->stacktrace(1);

If you are occasionally running queries where you expect to naturally
get exceptions (such as not inserting multiple values on a unique constraint),
then you can catch these separately:

  try { $self->schema->resultset('Unique')->create() };
  # Log any messages from try block, but only as trace
  $@->reportAll(reason => 'TRACE');

=head3 Email alerts of exceptions