Tres Seaver wrote:

>>> * The hook invokes the `query*` functions to play nice with any other
>>>    component hooks and the interface methods raise a TypeError if all of 
>>> them
>>>    fail to find a component.
>> A TypeError instead of a ComponentLookupError?
>> I was thinking we should keep the behavior as close to zope.component as
>> we can, including ComponentLookupError. Don't you get a
>> ComponentLookupError with the classic adapter hook too? So I'm -1 to
>> making this a TypeError.
> +1 to TypeError:  nobody really cares about the type of the error:  code
> that wants to be robust about a failure uses the 'query' methods.  As
> long as the message is informative enough (which ComponentLookupError
> isn't, really) we should be fine.  If we made CLE derive from TypeError,
> we could even still be satisfying the contract.

zope.component raises TypeError if you can't adapt. It raises 
ComponentLookupError it can't find a utility.

Let's keep exceptions the same. People do catch specific errors, so 
those who've done 'except TypeError' now aren't going to be happy if we 
change that to something else when they try to move to use the "new" API.

> - -1 to monkey patching:  I would favor exposing an API in zope.interface
> which allowed this kind of pluggability.

I agree.


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See

Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to