[Catalyst] Returning error codes to the user.

Tomas Doran bobtfish at bobtfish.net
Sun May 2 01:17:52 GMT 2010

On 30 Apr 2010, at 23:18, Bill Moseley wrote:
> But, for a tiny, tiny percent a request might fail.  Then the  
> question is *why* did it fail?  What WHERE condition or join failed?
> Just like our favorite topic premature optimization, I don't think  
> it would be wise to write the above in multiple stages (and multiple  
> requests to the database) just to check each step for something that  
> almost never fails.
> On the other hand, it's not unreasonable for an API request to  
> return a reason why something failed.  Sure would make tech  
> support's life easier.
> 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?)


More information about the Catalyst mailing list