[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
roles).
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.
Thanks,
-J
More information about the Catalyst
mailing list