[Dancer-users] Handling errors: Best Practices for Module extensions and Plugins

[Gurunandan Bhat]

My query was specifically for modules and plugins. For applications I
assumed that the Dancer::Error->new(...)->render would be the best thing to
do. Is my assumption right? It always made sense to me that the application
and the framework+helpers must die differently and I liked the fact that
Dancer::Error exists.

In CGI::App for example, applications register their own handler with the
core and all die()'s are trapped and forwarded with some minimal error
message to a custom handler if one exists. So while I believe that carp and
croak are best for core, I like what Dancer::Error offers while writing an
application - even in production.

Would love to be corrected on this.

Thank you.

On Wed, Dec 15, 2010 at 10:17 PM, sawyer x <xsawyerx at gmail.com> wrote:

> Theoretically in library code (this includes both plugins and Dancer
> itself, since it's a web-related DSL library, in essence) should use Carp's
> croak() and carp() in order to give the user (whoever is using Dancer or a
> specific plugin) with the correct line that was run that triggered the
> internal error.
>
> That means, theoretically, that all die()s and warn()s should be croak()s
> and carp()s.
>
> If you found any instances in which die() or warn() were used, it would be
> big (as in "kind and helpful") of you to contact the author (even us :) and
> tell them it exists and should probably be changed.
>
> The reason I said "theoretically" earlier is that perhaps a specific author
> would give you a compelling reason why they wanted die() instead of croak().
> Perhaps they know something you or I don't.
>
> Sawyer.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20101215/6c9fec83/attachment.htm>