[Zope-CMF] Re: [dev] some questions regarding Exceptions
Yuppie
schubbe at web.de
Fri Sep 12 11:33:22 EDT 2003
Hi!
seb bacon wrote:
> Yuppie wrote:
>> 1.) document_edit.py, metadata_edit.py and newsitem_edit.py in
>> CMFDefault are using this pattern:
>>
>> try:
>> context.edit( ...
>> context.REQUEST.RESPONSE.redirect( ...
>> except Exception, msg:
>> context.REQUEST.RESPONSE.redirect( ...
>>
>> Am I right that these excepts also catch ConflictErrors, what's a Bad
>> Thing in general and especially with edit methods?
>
>
> Yes, definitely. In general it's a Bad Thing to catch all Exceptions
> without exception, because the "swallow everything" approach masks
> problems in an unhelpful way. However, I guess these scripts are
> written as they are precisely so they can catch the string exceptions
> you mention.
You meant the other way round? 'except Exception' doesn't catch string
exceptions, only class exceptions.
>> 2.) There are still many string exceptions in CMF. All the others are
>> not accessible TTW.
>>
>> What would be the right way to resolve this?
>>
>> We could use allow_module() and allow_class(). I guess in that case
>> all Exceptions should be in one module. Something like
>> CMFCoreExceptions.py?
>
>
> I like that idea. If we design a core set of exceptions well, then
> folks can subclass them for their own needs and they'll still be caught
> by generic scripts.
Something like this?
class CMFError(StandardError):
...
class MembershipError(CMFError):
...
class MetadataError(CMFError):
...
...
> The big blocker I can see is that achieving backwards compatibility
> could be a struggle. I'm not sure about this though, someone would have
> to do a brief audit I guess.
If this is the way to go, I'd like to start using a new
CMFCoreExceptions.py for the new code I add in MembershipTool.py.
Updating the existing code could be done later. I have no idea how to
achieve backwards compatibility, but I think this should be done anyway.
Cheers,
Yuppie
More information about the Zope-CMF
mailing list