updates to CONTRIBUTING.md based on feedback

CONTRIBUTING.md

@@ -11,7 +11,7 @@ If you stumble upon a bug or something seems odd, please file an issue in the [i
 Fork, then clone the repo:
 
 ```
-git clone [email protected]:your-username/cinder/Cinder.git
+git clone --recursive [email protected]:your-username/cinder/Cinder.git
 ```
 
 Push to your fork and [submit a pull request][pr]. When describing your pull request, it is best to explain the problem you are solving or feature you are adding, some reasoning behind it, and how the code can be verified. If your modifications affect multiple platforms, please make a note of which platforms and OS versions you have tested on and which ones still need to be tested. If your contribution has already been discussed in an issue or forum post, linking to that may be a sufficient explanation.
@@ -38,7 +38,7 @@ Please make sure your code conforms to the following general guidelines. If some
 
 #### Spacing
 
-* Use tabs for indentation, with a tab stop value of 4
+* Use tabs for indentation, with a tab stop value of 4.
 * Anything inside a namespace starts with no indentation.
 * Place spaces between braces, braces and arguments, etc.
 * Brackets for class methods and functions begin on a new line. Brackets for everything else (class declarations, if / for / while loops, etc. ) begin on the same line following a space.
@@ -72,10 +72,10 @@ namespace cinder {
 //! More detailed information about SomeClass (optional)
 class SomeClass {
   public: // two leading spaces for access specifiers
-  	//! descrition of what you are constructing and any arguments passed in
+  	//! description of what you are constructing and any arguments passed in
   	SomeClass();
 
-  	//! Place spaces intbewteen braces and arguments.
+  	//! Place spaces in between braces and arguments.
   	void someMethod( int argA, const Rectf &bounds );
 
   	//! Inline simple methods by keeping the implementation on the same line as the declaration.
@@ -111,7 +111,7 @@ SomeClass::SomeClass()
 {
 }
 
-void SomeClass::someMethod()
+void SomeClass::someMethod( int argA, const Rectf &bounds )
 {
 	for( int i = 0; i < argA; i++ ) {
 		if( i + argB == 5 )
@@ -123,15 +123,15 @@ void SomeClass::someMethod()
 
 ```
 
-*Notes on shared_ptr usage*
+#### Notes on shared_ptr usage
 
-We use `shared_ptr`s a lot. Usually they are in the form of a typedef'ed `ObjectRef` to save the user a bit of typing (the `Ref` suffix is short for 'reference counted object`):
+We use `shared_ptr`s a lot. Usually they are in the form of a typedef'ed `ObjectRef` to save the user a bit of typing (the `Ref` suffix is short for 'reference counted object'):
 
 ```cpp
 typedef shared_ptr<class Object>	ObjectRef;
 ```
 
-Here are a couple rules of thumb regarding how to pass around these shared_ptr objects:
+Here are a couple rules of thumb regarding how to pass around these `shared_ptr` objects:
 
 Pass in by const &:
 
@@ -147,6 +147,13 @@ ObjectRef getObject() const;
 
 This is to avoid some nasty bugs that can be caused when the actual object returned is a subclass of `Object` and the method unwittingly returns a reference to an already destroyed temporary.
 
+
+#### Error Handling
+
+Avoid silent failures. In general, we use exceptions for cases that an application can recover from, such as when image decoding or glsl compilation fails. For situations that a user cannot possibly recover from, it is better to use assertions and the handy `CI_ASSERT` macro. However, as is the case many times, there are no rules set in stone for choosing one technique over the other, or choosing a different way to handle an error altogether (such as logging). When in doubt, post your code for peer review.
+
+Exceptions in core cinder code should all inherit from `ci::Exception`.
+
 [pr]: https://github.com/cinder/Cinder/pulls
 [issues]: https://github.com/cinder/Cinder/issues
 [const_correctness_1]:http://www.cprogramming.com/tutorial/const_correctness.html