[Catalyst] Catalyst best practices - exceptions

Ashley apv at sedition.com
Fri Mar 14 15:22:06 GMT 2008


On Mar 14, 2008, at 5:09 AM, Ian Sillitoe wrote:
> I'm curious about catalyst best practices regarding exceptions.  
> FWIW I found the following links outline a neat way of handling  
> Exceptions (i.e. tying additional functionality to typical HTTP  
> headers) and I'm currently using this model (not Model) in my  
> application.
>
> http://bricas.vox.com/library/post/catalyst-exceptionclass.html
> http://bricas.vox.com/library/post/catalyst-exceptionclass-detach.html
>
> I can't seem to find an enormous amount of discussion on the topic  
> - I wondered if anyone had any strong opinions on the matter? this  
> method in particular? whether this article should be slurped into  
> an entry on the new wiki?


It looks pretty nice. It's doing a lot of things that Catalyst  
already does; setting status, throwing exceptions. Since Cat catches  
all your exceptions and you have to deal with stuff in the end()  
anyway, my version does all the error checking and such then and I  
throw my exceptions with: die "RC_401: blah, blah, blah." The end()  
error catcher looks for the RC_[status_code] and uses HTTP::Status to  
return the name.

I posted a snippet of it to the list almost 2 years ago, I think, but  
those messages don't seem to be in the archive. Someone also has a  
plugin to do some of this; the name escapes me.

I print the error stack (I have two versions, one regular errors, one  
that shows the guts of StackTrace) with the status message if the app  
is running under debug so that users just see "404 Not found: /asdf/ 
asf/asdf" and developers see the works. Since there can be many  
errors thrown (as Laurent Dami is asking in another thread), normal  
users just get the first error thrown out of $c->errors. Developers  
get the whole mess in case it matters.

-Ashley




More information about the Catalyst mailing list