[Catalyst] Returning error codes to the user.

J. Shirley jshirley at gmail.com
Sun May 2 14:57:58 GMT 2010

On Sun, May 2, 2010 at 7:28 AM, Bill Moseley <moseley at hank.org> wrote:
> On Sat, May 1, 2010 at 6:17 PM, Tomas Doran <bobtfish at bobtfish.net> wrote:
>>> So, what would you recommend? Have a separate /user/$id/debug method that
>>> does a separate step-by-step of the business logic?  Scrap all that really
>>> handy chaining of resultsets that works so well with Catalyst's chained
>>> actions?
>> Given that 'a tiny, tiny percent a request might fail', why not do the
>> step by step for the tiny failed set and then present the reason to the user
>> for those?
>> (Or am I missing something obvious here?)
> You are not missing anything if that's your recommendation.  I assume lots
> of people here are creating real web applications with Catalyst so was
> inquiring how others handle this situation in the design of their
> applications.
> I have a CRUD controller base class to help generate a RESTful-like API that
> is used by both API users and with an AJAX-based application, which I assume
> is not that uncommon with Catalyst apps.  For example, when a PUT
> /thingy/52113 fails (which means the query used to fetch the item failed),
> how do you reported to the user?  A 404 with a text description?  Some kind
> of error code in the response body?
> I my case, I'm added a method explain_not_found() to the base class that can
> be overridden in the controller to provide specific details in textual
> format.  That method would be used to break the query into parts to test
> each join and condition, for example.
> As a side note: Frankly, I enjoy the discussions of real problems and
> solutions on this list.   I try not to find it discouraging that old topics
> like benchmarking methods calls and the few inflammatory remarks seem to get
> so much traction.   :)

My method is simply to use chained, and on the _REST action defer to a
not_found... but this is using base classes (and a conversion to

So, if I want to specialize thingy's not found action I just drop a
method in there... otherwise the base controller not_found is called,
which sets a template for any browser (and the entity/message stuff
works as expected).

If it's not a browser they only get a formatted message via
C::C::REST->status_not_found, if they are I also set a template that
tries to find a not_found.tt in that action namespace (same as what
you expect w/ Catalyst::View::TT), and if that doesn't exist it goes
to the shared not_found.tt.

That template is pretty easy:

TRY; PROCESS "$c.action.namespace/not_found.tt"; CATCH file; PROCESS
"errors/not_found.tt"; END;

What's next on my list is to tie in status helpers into my
Message::Stack work (not yet released) that applies scope knowledge to
the error messages.


More information about the Catalyst mailing list