[Cosmo-dev] JS error-handling in the UI
mde at osafoundation.org
Tue Jul 31 15:52:20 PDT 2007
Agreed 100%. And when we can implement something that doesn't prevent us
from using normal debug tools when we're working on the app, I'll be
behind that wholeheartedly.
I'll be happy to help in whatever way needed to implement something like
that for all client-side errors -- the key being that it can be easily
and permanently disabled in the dev environment (i.e., no local changes
to files you have to worry about getting committed/overwritten with svn).
Bobby Rullo wrote:
> The application is meant to be used by users, not developers. And they
> expect a nice dialog box when something (god forbid) goes wrong, not
> On Jul 31, 2007, at 3:15 PM, Matthew Eernisse wrote:
>> Two reasons:
>> 1. Consistency. Right now all generic JS errors generated by the UI
>> code log to the console.
>> 2. Efficiency/usability. Waiting for the modal dialog to pop, clicking
>> the details link, popping up a new window, and scrolling to see all
>> the stack is makes it much slower to do iterative debugging -- which
>> is something I spend a lot of time doing. The Firebug error console
>> has a lot of niceties for both logging and viewing errors all in one
>> place that makes it much better for debugging than our home-rolled
>> solution (with all due respect to the work you've done to make it more
>> Now, if later we decide we'd like to design something that handles all
>> errors in a unified way (e.g., hiding all of them behind the modal
>> dialog facade we have now), and it's something that can be easily and
>> permanently disabled in the dev environment to allow use of normal
>> debugging tools, I'd be all for it.
>> Bobby Rullo wrote:
>>> So why is that behavior desirable? The point of addErrback is that it
>>> handles errors...why do you want stuff going to the console?
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
More information about the cosmo-dev