[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pulp-list] Errors in controllers

On Fri, 2012-02-10 at 09:11 -0500, Jay Dobies wrote:
> I was thinking about the deep dive yesterday and I think slagle's got
> a 
> really good idea on the changes we should make to the error
> serialization.
> We already have a hook deep in the bowels of our web stuff to catch
> any 
> unexpected exceptions, wrap them in our standard format, and raise
> them 
> as 500s. That hook could look for one of a standard set of base 
> exceptions (~6 I'd guess) and wrap with the appropriate status code.
> The exception base classes would come out of the manager layer. 
> Conceptually, it's not REST-specific for the manager layer to identify
> a 
> distinction between "missing" and "bad data". Each manager can
> subclass 
> those as necessary/appropriate. That keeps the manager layer 
> front-end-agnostic but gives the info the REST layer needs.
> So somewhere in our web layer, something like:
> try:
>    # any controller method
> except MissingResource, e:
>    serialize_404(e)
> except BadData, e:
>    serialize_400(e)
> except DuplicateId, e:
>    serialize_409(e)
> except Exception, e:
>    serialize_500(e)
> That should remove some of the busy-work from the controllers since
> the 
> call to the managers shouldn't need to be wrapped in any exception 
> handling, they can bubble up and be handled by the web framework. We 
> just need to be very careful that the managers are written using the 
> right exceptions.
> We'll still need access to the serialize methods for cases where it's
> a 
> non-exception case (e.g. missing parameter from the request body),
> but 
> that's the rare case. 

This is an absolutely fantastic idea. I've started on the changes to the
web framework. I'm going to put down some base exceptions based on
what's in this email, and I'll present them next week on Tuesday when I
talk about _id v id as well.

Jason L Connor
linear on freenode #pulp
RHCE: 805010912355231
GPG Fingerprint: 2048R/CC4ED7C1

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]