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

[Bobby Rullo]

Matthew,

If you explain in plain language what you need that having the  
information as it was in the pop-up didn't provide you that would be  
helpful.

So far you've mentioned formatting, and that you don't like that it's  
in a separate window. Is there anything else?



On Jul 31, 2007, at 9:47 PM, Matthew Eernisse wrote:

> Jared,
>
> Reverting to the previous unhelpful no-info popup absolutely is not  
> and never was on the table. In fact, the pop-ups were the original  
> problem.
>
> This entire thread started because changes to the error handling  
> resulted in JavaScript errors from UI-layer code that used to go to  
> the console (where you could inspect them) to be re-routed to an  
> error-handling mechanism that was designed to handle reporting of  
> server-side/service errors and user-input validation errors (where  
> you could not).
>
> A JavaScripty modal dialog box is great for telling the user they  
> entered a wrong date format, and a separate browser window is  
> perfect for showing things like a server-side error stack trace.  
> But faux modal dialogs and pop-up windows are not the ideal tools  
> for iterative development of an Ajaxy UI.
>
> I know this because I have spent years of my life (I'd like them  
> back, please) using precisely those kinds of homerolled debugging  
> tools. We actually have a decent tool like Firebug for debugging UI  
> errors now, and I don't want to go back in time to the days when we  
> were dumping stuff into a pop-up window.
>
> It's not like we've been talking about some pre-planned or system- 
> wide change to error handling here -- what has happened in this  
> case is that errors from a piece of the UI code *near the service  
> layer* were pulled into the error reporting mechanism for the  
> service layer. It's nothing anyone planned or designed to happen  
> that way.
>
> My suggestion for moving forward is that we put our heads together  
> and decide if we actually want to handle all (or some, how much of)  
> the errors that may occur in JS execution in the UI code ourselves  
> -- and if we do, how we want to handle it. I don't know of any  
> other Ajaxy apps that attempt to preempt the normal JavaScript  
> error-reporting mechanism with their own, but that's not to say  
> that we could not or should not do that.
>
> The benefits of doing that would be just what Bobby says -- it  
> would be way, way more user-friendly. The drawbacks are extra work  
> and added complexity -- e.g., making sure we can deal with cases  
> where our error-handling code itself produces errors. (Something  
> that the errBack from the deferred seems not to be doing correctly;  
> rethrowing from inside the error-handling block of code does  
> nothing. I don't know enough about the deferred thing to guess why.)
>
> The benefits of letting JS handle JS errors are obvious -- we don't  
> have to work to bulletproof potentially hairy error-handling code,  
> and we can be sure that the error will always be reported duly to  
> the JS console. The downside of course is that it's less user- 
> friendly -- and even though most users of Web apps have at least a  
> passing familiarity with the idea of a 'JavaScript errors,' they  
> don't all necessarily know where to look for the content of the  
> error message right off the bat.
>
> If we were to decide to try to implement error handling for all  
> client-side errors ourselves, for me the most fundamental  
> requirement would be that our stock dev environment doesn't require  
> debugging by dumping stuff into a pop-up window like we were doing  
> back in the year 2000.
>
> Thanks.
>
>
> Matthew
>
>
> Jared Rhine wrote:
>> Bobby Rullo wrote:
>>> to have errors cause the UI to respond in a user-unfriendly way  
>>> is unacceptable...
>> +1
>> I hear Matt's problem and support his desire for errors to be dev- 
>> friendly.  But reverting to the previous popups shouldn't be on  
>> the table; only moving forward with enhancements to have the error- 
>> reporting mode be configurable (IMO).
>> It's a bummer that no specifications/plans addressed error  
>> conditions previously as it's so fundamental to a good user  
>> experience.  What are you suggesting as a way forward, Matt?
>> -- Jared
>> _______________________________________________
>> 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