Handling errors: Best Practices for Module extensions and Plugins
I have seen plugins and modules that extend the core (Dancer::Session::X for instance) handle fatal errors in diverse ways: die and croak for one. Are there best practices for die'ing from a use'd module or plugin? Thank you
I personnally prefer croak to die, and carp to warn. Ideally, I would croak a instance of a dedicated Dancer error class ? Something inspired by this : http://advent.rjbs.manxome.org/2010/2010-12-03.html Originally, Dancer was using warn and die, and I introduced some croak and carp calls. My evil plan was that it would extend itself to any Dancer core and plugin code, but I didn't explicitely pushed anything. The call has to be made by $designer I guess :) On 15 December 2010 16:41, Gurunandan Bhat <gbhat@pobox.com> wrote:
I have seen plugins and modules that extend the core (Dancer::Session::X for instance) handle fatal errors in diverse ways: die and croak for one. Are there best practices for die'ing from a use'd module or plugin?
Thank you
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Thanks, noted. On Wed, Dec 15, 2010 at 9:48 PM, damien krotkine <dkrotkine@gmail.com>wrote:
I personnally prefer croak to die, and carp to warn. Ideally, I would croak a instance of a dedicated Dancer error class ? Something inspired by this : http://advent.rjbs.manxome.org/2010/2010-12-03.html
Originally, Dancer was using warn and die, and I introduced some croak and carp calls. My evil plan was that it would extend itself to any Dancer core and plugin code, but I didn't explicitely pushed anything.
The call has to be made by $designer I guess :)
On 15 December 2010 16:41, Gurunandan Bhat <gbhat@pobox.com> wrote:
I have seen plugins and modules that extend the core (Dancer::Session::X for instance) handle fatal errors in diverse ways: die and croak for one. Are there best practices for die'ing from a use'd module or plugin?
Thank you
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
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.
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@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.
Dancer::Error is used to produce an error to show the user. If you have the proper configuration, Dancer will present the user with your errors (die(), croak() included). You can use Dancer::Error yourself if you want to force a web-viewed error. If you don't want such specifics, just throw a fit (or an exception :) and Dancer will handle it by configuration (show the user, provide it in logs, etc. etc.). On Wed, Dec 15, 2010 at 7:46 PM, Gurunandan Bhat <gbhat@pobox.com> wrote:
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@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.
participants (3)
-
damien krotkine -
Gurunandan Bhat -
sawyer x