NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
use Perl Log In
LTjake (4001)
Monday April 09, 2007
05:06 PM
Catalyst + Exception::Class + detach
After re-reading my last post, I realized that I neglected to mention one special exception: $Catalyst::DETACH.
When you call $c->detach(, underneath it calls $c->forward( then dies with a special detach message. Unfortunately, all of our exception handling will catch this too. It's pretty easy to clean this up in our end action:
sub end : Private {
my( $self, $c ) = @_;
if( my( $error ) = @{ $c->error } ) {
if( $error->message eq $Catalyst::DETACH ) {
$c->clear_errors;
}
else {
return;
}
}
# continue on as normal...
}
Without that cleanup, you'd get the error screen every time you would call detach().
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
an endless discussion thread about what features to include.
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
++ to all this (Score:1)
I've used custom exceptions for ResourceNotFound, InvalidIdentifier and such regularly in applications in the past and it worked quite well. I also experimented with an un-auto like catching mechanism. For example, the chain segment Foo::Bar::load would throw an ResourceNotFound::Bar exception if it can't find a bar with the passed ID. It would then search in Foo::Bar, and then in Foo for exception handling actions that fit the criteria (catching ResourceNotFound::Bar, ResourceNotFound or FlowException).
I
Ordinary morality is for ordinary people. -- Aleister Crowley
Re: (Score:1)
Great idea! It seems like we're inching towards a more robust idea of exception handling.
Right now I'm pretty happy encapsulating some logic inside each exception class -- though something more closely tied to the application would likely be better in some instances.