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.