[Zope-CMF] Re: [dev] exceptions (small post-permissiongeddon proposal)

Tres Seaver tseaver at zope.com
Tue May 4 01:27:36 EDT 2004


yuppie wrote:

> Tres Seaver wrote:
> 
>> Sidnei da Silva wrote:
>>
>>> -1 for #2, as I think that a thirdy party product expected to replace
>>> CMFDefault may want to reuse the same exceptions to keep as much
>>> compatibility as possible and avoid a dependency on CMFDefault.
>>
>>
>>
>> The only one I see which is CMFDefault-specific is IllegalHTML;  
>> nothing in the core knows raises or catches it, nor should.  Any 
>> product which *wants* to know about this exception depends on 
>> CMFDefault anyway;  it is only interesting if you are using / deriving 
>> from Document.  +1 for moving it to CMFDefault.exceptions.
>>
>> OTOH, EditingConfilic is a *much* more "framework-ish" exception, 
>> which would reasonably be used by multiple products.  -1 for moving it 
>> out of CMFCore.exceptoins.
> 
> 
> EditingConflict belongs to the safety belt machinery. Safety belt is 
> used in CMFDefault and products depending on CMFDefault. CMFCore doesn't 
> define / implement this machinery in any way.
> 
> So if you ask me, EditingConflict doesn't belong into CMFCore.

OK, you've persuaded mem.  I didn't go looking for what code actually 
used the exception, but was thinking about what the name suggested.

> There are still many string exceptions that need to be replaced. An easy 
> rule where to put and find these exceptions would be quite helpful. 
> "framework-ish or not" isn't a simple rule.

String exceptions delenda est!

OK, how about "if the exception is part of a framework interface's 
contract"?  Frankly, if we are raising non-standard exceptions *without* 
mentioning them in the interface, then that should be remedied as well.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com



More information about the Zope-CMF mailing list