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

[Matthew Eernisse]

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
>