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?)
Cheers
t0m
_______________________________________________
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/
