[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