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

[Matthew Eernisse]

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
>