[Cosmo-dev] JS error-handling in the UI
br at osafoundation.org
Mon Jul 30 22:39:58 PDT 2007
That's just what I need to know! I'll have a fix in the morn'.
On Jul 30, 2007, at 10:04 PM, Matthew Eernisse wrote:
> 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:
> 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.
> 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...
>> On Jul 30, 2007, at 8:09 PM, Matthew Eernisse wrote:
>>> Looks like changes to the error-handling code for saving/removing
>>> have had some unfortunate side-effects.
>>> *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
>>> (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
>>> cosmo-dev mailing list
>>> cosmo-dev at lists.osafoundation.org
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
More information about the cosmo-dev