313
edits
Exceptions: Difference between revisions
→outparamdel
| Line 80: | Line 80: | ||
With exceptions in place, <code>nsresult</code> methods become <code>void</code>-returning methods. Thus, methods with an "outparam" (more formally, a pointer-typed argument designated for passing a result out of the called method) will be able to place their result directly in the return value. This will make life easier for programmers and may save a few processor cycles. | With exceptions in place, <code>nsresult</code> methods become <code>void</code>-returning methods. Thus, methods with an "outparam" (more formally, a pointer-typed argument designated for passing a result out of the called method) will be able to place their result directly in the return value. This will make life easier for programmers and may save a few processor cycles. | ||
We already have a tool called [outparamdel] for doing this refactoring. It hasn't been used yet because it can't really be done before exceptions. (Many getter methods always succeed, so we could technically apply [outparamdel] without exceptions, but it's risky because it assumes (a) the method will never be changed so that it can fail, and (b) the method isn't implemented in JavaScript. Neither assumption is safe.) | We already have a tool called [[outparamdel]] for doing this refactoring. It hasn't been used yet because it can't really be done before exceptions. (Many getter methods always succeed, so we could technically apply [[outparamdel]] without exceptions, but it's risky because it assumes (a) the method will never be changed so that it can fail, and (b) the method isn't implemented in JavaScript. Neither assumption is safe.) | ||
== Automated Refactoring == | == Automated Refactoring == | ||