[Cosmo-dev] JS error-handling in the UI

[Matthew Eernisse]

It's not a question of what information is missing -- it's the fact that 
it's slower and requires multiple clicks to get to it, it's in a 
different place from all the other debug info I'm working with, it's in 
an awkward separate window, the formatting is hard to read, and that the 
detailed debug info isn't easily displayed/hidden like it is in the 
Firebug console.

The bottom line is that it's very, very nice for end-users -- but it's a 
big step backward compared to the Firebug console, and would be a 
significant drag on my productivity. Once we can confine it to the 
end-users, that will be great -- until then, no thank you.


M.

Bobby Rullo wrote:
> What are you not getting in that dialog box that you need?
> 
> bobby
> On Jul 31, 2007, at 3:52 PM, Matthew Eernisse wrote:
> 
>> 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).
>>
>>
>> M.
>>
>> Bobby Rullo wrote:
>>> Well,
>>> 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 just silent failing with a little javascript error in the corner.
>>> bobby
>>> 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 usable).
>>>>
>>>> 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.
>>>>
>>>>
>>>> M.
>>>>
>>>> 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?
>>>>> bobby
>>>>
>>>> _______________________________________________
>>>> cosmo-dev mailing list
>>>> cosmo-dev at lists.osafoundation.org
>>>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>>
>> _______________________________________________
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>