[Bf-python] Re: [Bf-blender-cvs] CVS commit: blender/source/blender/include BDR_editcurve.h BIF_editarmature.h BIF_meshtools.h blender/source/blender/python/api2_2x Object.c blender/source/blender/python/api2_2x/doc Object.py blender/source/blender/src editarmature.c editcurve.c meshtools.c

[Campbell Barton]

Toni Alatalo wrote:
> On Tuesday 03 January 2006 04:35, Campbell Barton wrote:
>   
>>   Made respective join_* functions return 0 if the join was not mode, 1
>> when it workes.
>> -73   blender/source/blender/python/api2_2x/Object.c
>>     
>
> 	@return: 0 is returned if the join is not successfull, otherwise 1 will be 
> returned.
>
> i object this, and prefer failing operations to raise exceptions.
>
> there are some parts in the bpy api that dont, so arguably that addition is 
> consistent with some existing things. but i hope inconsistent with even more 
> of bpy, and i think with all of normal py .. or?
>
> is there some other reason for returning a value upon failure, like being 
> afraid of causing unhandled exceptions in scripts?
>
> i suggest (again) we always adhere to the 'samurai principle' like normally in 
> Python  http://c2.com/cgi/wiki?SamuraiPrinciple
>  
> have had painful experiences in bpy scripting when .. ah, now i see this case 
> is not that bad: the pain is in cases where in normal case an object to be 
> worked on later is expected, but e.g. a None is gotten instead. this is the 
> case with 
> http://www.blender.org/documentation/240PythonDoc/Ipo.Ipo-class.html#getCurve 
> which Returns: the corresponding IpoCurve, or None. 
>
> that can hide bugs, be nasty.
>
> perhaps this joining too?
>
> like when you have code where join, assume it always succeeds, and then 
> operate on the objects later .. and get weird results, or a strange bug in 
> later code, and dont see that it was the join that failed and not some later 
> operation / your general logic / .. disclaimer: i dont know when joining can 
> fail.
>
> sorry for the long messy post, must get more sleep now, but i hope the point 
> got thru.
>
> and thanks for all this great work, i hope you dont mind us all being such 
> asses! :)
>
> ~Toni
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python
>   
Hay Toni, Will probably change- its not as simple as other cases though.
join may fail because of a bad list, or object of the wrong type- eg- 
badly coded python.
but join may not happen because a mesh has keys, or too many verts...

if they check for both eg
try:  
    worked = ob.join(objects)
except:
    print error in python code'
if not worked:
    print 'error in input data'

Python coders should realy check that thw join worked and not just 
assume it did.
Maybe Ill have defferent exceptions for input error and blender join failier
 just document how try/except should be used with this function.

- Cam

-- 
Campbell J Barton

133 Hope Street
Geelong West, Victoria 3218 Australia

URL:    http://www.metavr.com
e-mail: cbarton at metavr.com
phone: AU (03) 5229 0241