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

[Bobby Rullo]

Matthew,

You're welcome.

I read this comment, and you commit and I still don't understand.  
Could you explain this a little more? Like what you mean by "stuck in  
the addErrBack" and "nomal error handling"

Thanks,

bobby

On Jul 31, 2007, at 12:46 PM, Matthew Eernisse wrote:

> Bobby,
>
> Thanks muchly. This looks great -- this means much less head- 
> scratching when unanticipated JS errors occur in the service layer.
>
> It's still less than optimal to have all the generic JS errors from  
> the UI code *following* the service call stuck in the addErrBack  
> for the service Deferred. I've added code so that the success  
> message is published in window scope, so that UI code errors will  
> work the same way after saving as they do everywhere else.
>
> Thanks again for jumping in to help fix this.
>
>
> M.
>
>
> Bobby Rullo wrote:
>> Ok Matthew, the fix is in!
>> Note that to see it work you should do "throw new Error('foo')" -  
>> in your example you were just throwing a string, which obviously  
>> doesn't contain stack and all that stuff.
>> bobby
>> On Jul 30, 2007, at 10:04 PM, Matthew Eernisse wrote:
>>> Bobby,
>>>
>>> By 'swallowed,' I just what you said -- the errors are being  
>>> handled (for some value of 'handled' :)) by the dialog box  
>>> instead of the code simply failing and the error going to the  
>>> console.
>>>
>>> This is in the saveSuccess function in cosmo/view/cal/canvas.js.
>>>
>>> To produce it so I could figure out what was happening, all I did  
>>> was put:
>>>
>>> throw('foo');
>>>
>>> at the very beginning of the saveSuccess method, before any other  
>>> code executes.
>>>
>>> It appears that the dialog in that case is from handleSaveItem,  
>>> on line 395 of cosmo/view/service.js. (I'm guessing it's the  
>>> addErrBack from the deferred?) I verified that by console.logging  
>>> the err object just before cosmo.app.showErr gets called.
>>>
>>> Yeah, putting all of the info (file name, line number, stack,  
>>> etc.) in our error box details pop-up would make this much less  
>>> of a problem when our code does actually catch a generic JS Error.
>>>
>>> Thanks.
>>>
>>>
>>> Matthew
>>>
>>> Bobby Rullo wrote:
>>>> I'm not sure exactly what you mean here. If you are getting an  
>>>> error in the dialog box then an error IS being caught and dealt  
>>>> with, so I am not sure what you mean by swallowed.
>>>> AFAIK I am not try/catching anywhere that isn't making server  
>>>> calls, so those errors shouldn't get handled by the dialog box,  
>>>> they should just fail and the browser will handle them however  
>>>> it does by default. There maybe places where that is not the  
>>>> case though, so it would be helpful if you could let me know  
>>>> where this is happening.
>>>> Also, I took out the code that was displaying the error messages  
>>>> in the dialog box from the exception directly to the user -  
>>>> users shouldn't see stuff like "x has no properties" or  
>>>> something. Of course, I should've made the JS Exception  
>>>> information available somewhere, so my bad.
>>>> I'll put in some code to make sure that information is available  
>>>> first thing in the morning...
>>>> Thanks!
>>>> bobby
>>>> On Jul 30, 2007, at 8:09 PM, Matthew Eernisse wrote:
>>>>> Howdy.
>>>>>
>>>>> Looks like changes to the error-handling code for saving/ 
>>>>> removing have had some unfortunate side-effects.
>>>>>
>>>>> Now normal JavaScript errors happening in the canvas repaint  
>>>>> *after* saving are being swallowed, and all I get is the  
>>>>> generic "Could not save the item" error in our modal dialog box.
>>>>>
>>>>> This is problematic firstly because the items actual *is* being  
>>>>> saved -- the error is simply in the canvas repaint. Of course  
>>>>> the bigger issue is that now all the normal information you'd  
>>>>> get in the JavaScript debug window or in Firebug is now  
>>>>> unavailable. (Shades of JSON-RPC grabbing all its errors and  
>>>>> sticking them by default in an alert box, although this is a  
>>>>> bigger problem because it extends up out of the service layer  
>>>>> now.)
>>>>>
>>>>> Could we do something about this? Seems like we should be  
>>>>> grabbing errors of the type we care specifically about, and  
>>>>> passing on all the others to be handled the normal way, if  
>>>>> that's possible.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> Matthew
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> _______________________________________________
>>> 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