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

[Matthew Eernisse]

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
>