874
edits
Labs/Jetpack/Reboot/Best Practices: Difference between revisions
Jump to navigation
Jump to search
Labs/Jetpack/Reboot/Best Practices (view source)
Revision as of 10:12, 11 February 2010
, 11 February 2010Added section on exception logging
(Added sections on testing, module unloading, module instantiation, memory leak prevention) |
(Added section on exception logging) |
||
| Line 38: | Line 38: | ||
* Add [http://hg.mozilla.org/users/avarma_mozilla.com/atul-packages/ atul-packages] to your <tt>packages</tt> directory and then pass <tt>--extra-packages=nsjetpack</tt> to <tt>cfx</tt> when you run your tests. This will cause the test runner to enable optional [[Labs/Jetpack/Binary_Components#Memory_Profiling|JS memory profiling functionality]] and display extra JS object statistics between iterations. In particular, a "diff" of the JS heap from one iteration to the next is displayed, which can be helpful in pinpointing where a leak is occurring. | * Add [http://hg.mozilla.org/users/avarma_mozilla.com/atul-packages/ atul-packages] to your <tt>packages</tt> directory and then pass <tt>--extra-packages=nsjetpack</tt> to <tt>cfx</tt> when you run your tests. This will cause the test runner to enable optional [[Labs/Jetpack/Binary_Components#Memory_Profiling|JS memory profiling functionality]] and display extra JS object statistics between iterations. In particular, a "diff" of the JS heap from one iteration to the next is displayed, which can be helpful in pinpointing where a leak is occurring. | ||
= Exception Logging = | |||
We want to be able to track uncaught exceptions in a much richer way than Mozilla's <tt>nsIConsoleService</tt> currently allows. For instance, we want to be able to filter messages on a per-Jetpack basis, possibly even a per-module basis, and we also want full stack tracebacks. | |||
In order to do this without making pervasive modifications to the Mozilla platform, we're simply catching exceptions before they propagate into platform code, and logging them via a call to <tt>console.exception()</tt>. | |||
Any platform event handlers your code registers should be "wrapped" such that this is the case. | |||
= More Stuff = | = More Stuff = | ||
| Line 48: | Line 56: | ||
* localization | * localization | ||
* API design | * API design | ||
* Some Cuddlefish modules, like file.js, take pains to be broadly compatible as JS modules and loadable | * Some Cuddlefish modules, like <tt>file.js</tt>, take pains to be broadly compatible as JS modules and loadable via <tt>script</tt> tags in XUL documents, in addition to being CommonJS modules used in Jetpack. Do we really want to go that route for all modules? | ||
* When creating objects, do we want <tt>jetpack.thing()</tt> or <tt>new jetpack.Thing()</tt>? | * When creating objects, do we want <tt>jetpack.thing()</tt> or <tt>new jetpack.Thing()</tt>? | ||
** Atul has found the case of forgetting the "new" operator to be unforgivingly difficult to debug. | ** Atul has found the case of forgetting the "new" operator to be unforgivingly difficult to debug. | ||
** Atul has also found that "new" operator problems are hard to debug when the operator associates w/ a different operand than one intends, e.g. <tt>new require("foo").Bar()</tt>. | ** Atul has also found that "new" operator problems are hard to debug when the operator associates w/ a different operand than one intends, e.g. <tt>new require("foo").Bar()</tt>. | ||