[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