Harvesting and deprecation - exception naming conventions

Stephane Ducasse ducasse at iam.unibe.ch
Fri May 9 13:04:58 UTC 2003


Agree so which one? I have no idea


On Friday, May 9, 2003, at 02:48 PM, Brent Pinkney wrote:

> Lads,
>
> I do not wish to be a-retentive, but I think we need some policy on 
> the naming of exceptions.
>
> The ANSI spec introduces nicely named exceptions like DiveByZero and 
> MessageNotUnderstood.
>
> We seem to be introducing things like
> #MyTestError
> #VMMakerException
> #FileExistsException
> #CannotDeleteFileException
> #XMLWarningException
> #InvalidDirectoryError
> #SAXException
> #XMLInvalidException #FileStreamException #FileDoesNotExistException 
> #SAXMalformedException #SAXParseException #XMLMalformedException 
> #ProgressInitiationException #ApplescriptError #Error #SyntaxError 
> #Exception #XMLException #MyResumableTestError > #FTPConnectionException)
>
> DeprecatedException so
>>> that we can
>>> trap them specifically.
>>>
>>> So we do not follow the deprecated pattern a la java in the
>>> sense that
>>> we do not say in the future this method will be deprecated and still
>>> let it. We were thinking that we could
>>> go faster than way.
>>>
>>> But I like your idea to add deprecated in ProtoObject.
>>>
>>> For now I was doing that this way
>>>
>>> allBehaviorDo: aBlock
>>>
>>> 	self flag: #deprecated.
>>> 	self error: 'This method is deprecated please use
>>> SystemNavigation>>allBehaviorDo:'
>>>
>>>
>>>
>>> Stef
>>>
>>> On Friday, May 9, 2003, at 09:45 AM, Brent Pinkney wrote:
>>>
>>>> OK,
>>>>
>>>> I have been following the harvesting thread for a while now
>>> and have
>>>> been called apon to revide my DateAndTime stuff. This
>>> removes a couple
>>>> of yucky methods that have crept into Date and Time.
>>>>
>>>> What is the preffered method of deprecating classes and methods ?
>>>>
>>>> In the full image of yore it was relatively simple. In the
>>> SqueakMap
>>>> era, how do I know I can cull a redundant or yucky method/class ?
>>>>
>>>> The alternative for endless backward compatibility seems to
>>> be a cop
>>>> out. A tight lean elegant implementation is important.
>>>>
>>>> I propose calling ProtoObject>>#deprecated in the to be deprecated
>>>> method. Two versions later this should cause and exception.
>>>> Alternatively move the methods to the deprecated category, although
>>>> this may not play nicely with DVS.
>>>>
>>>> Ideas ?
>>>>
>>>> Cheers
>>>>
>>>> Brent
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
>



More information about the Squeak-dev mailing list