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
_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
