[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

[Stephen Swaney]

On Tue, Jan 03, 2006 at 03:56:40PM +1100, Campbell Barton wrote:
> 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.

Willian and I were talking about exceptions today as part of the 
general principles we would like the API to follow.  Basically, when
something goes wrong or not as expected, always return an exception.

Exceptions are unfamiliar to some, but using them really does simplify 
error handling and makes the code cleaner.

Some of our older methods return C-like status codes but this will
be fixed up soon for consistency.

Here is a list of standard exception types:
http://docs.python.org/api/standardExceptions.html

Common ones for us are going to be things like KeyError, AttributeError,
NameError and IndexError for example.

It is possible that a method may throw more than one exception
type from different places as a result of different types of failure.
If nothing seems to fit, you can always fall back on a RuntimeError

General Rule:  use exceptions, not return codes.

-- 
Stephen Swaney			
sswaney at centurytel.net