[Dancer-users] Dancer::Exception

damien krotkine dkrotkine at gmail.com
Mon Aug 8 17:05:23 CEST 2011


Hi,

I'm in the midle of doing the second round coding for Dancer::Exception
(it's in topic/exceptions2 on github). I have few design questions, and I'd
like some feedback from the community.

The plan is that with Dancer::Exception :
- 1/ an exception has a value ( combination of power of 2 integers), and a
message (string)
- 2/ all exceptions raised by the Dancer core will be Dancer::Exception
(instead of normal die / croak)
- 3/ a user will be able to raise exceptions in the routes
- 4/ a user will be able to create new exception types
- 5/ when raised, exceptions are transmitted to the templating system when
rendering a Dancer::Error
- 6/ exceptions should properly stringify and numerify for backward
compatibility and ease of use.
- 7/ the user should have the opportunity to catch any Dancer exception and
perform an appropriate action

Currently, in the topic/exceptions2 branch, all items are implemented,
except item 7. More precisely, it's possible to catch Dancer::Exception
using standard eval {...}. But what if a user wants to catch an exception
raised from a distant route, or from Dancer Core itself ?

Real life example 1 : in some routes, the developer does some 'raise' of
exceptions (internal or custom). The developer wants to run specific codes
when these exception are raised. For now, he can wrap his route code with
eval {} and use is_dancer_exception, as stated in Dancer::Exception.

Real life example 2 : in some routes, the developper wants to catch core
exceptions that could occur.

Real life example 3 : if something wrong happens in the
Dancer::Session::Yaml modules, it raises a E_SESSION exception. When this
exception occurs, it'll render a Dancer::Error, stating that thet exception
were a E_SESSION. However what would be cool is that you could catch the
exceptions, see that it's of type SESSION, and in this case try a different
Dancer::Session system. In this case the exception is a core one.

example 3 is not related to routes, so it's a bit difficult to know where to
put a try/catch scope.

I have some ideas, but I'm not really convinced by them :
- idea 1 :  add a new hook, that would be called 'after_exception'
- idea 2 : when an exception is raised, it's stored as Shared Data, and thus
can be detected with a before_error hook
- idea 3 : add a try_catch syntax when creating route, like :

get '/foo' => sub { ... raise E_LOGIN, "bad credential" },
       catch E_REQUEST | E_GENERIC => sub { ... }
       catch E_LOGIN => sub { ... }

Currently, Dancer::Exception is not too bad : it's simple, efficient and
fast. I don't want it to become a bloated system. But we need to provide a
bit more feature for it to be really useful.

Please share your thoughts :)


dams.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20110808/922007c4/attachment.htm>


More information about the Dancer-users mailing list