[dojo-contributors] Async Errors...

Mike Wilcox mike at mikewilcox.net
Tue Jun 5 11:51:48 EDT 2012


Ok, so there is no opt-in and this is to be standard functionality - that's cool. But the parser swallows errors, and that's uncool. 

I definitely appreciate your efforts on the parser, especially to make adoption of Dojo easier (you have been kicking ass and taking names). The new loader has multiple incredible features, but the main one I have been championing is that Dojo finally handles syntax errors gracefully - so hiding them again seems a step backward to me. 

IMHO, Having to attach a special error handler to almost everything I do is unintuitive to JavaScript, and smacks of littering my code with try-catches.  Optimally, Promises should come with a default handler that can throw an "un-caught" error. That would be an amazing help to developers at such little cost in effort and bytes, and would be so much more user friendly than telling them they are doing it wrong.  

In lieu of that getting any kind of consensus on my side note, I think it would be a good idea to at least put an error handler in the parser, even if it throws a redundant error, so as to not confuse and frustrate the developers we are hoping will adopt Dojo. 

Mike Wilcox
http://clubajax.org
mike at mikewilcox.net



On Jun 5, 2012, at 1:55 AM, Kitson Kelly wrote:

> Easier said than done.  It would require two wholly separate code paths in the parser, because getting the parser to deal with the potential async nature of require, the whole of the parser is now written to handle things in an async fashion, even if the code is executed synchronously.
> 
> We specifically discussed opting-in, but the two new features (auto-require, declarative require) we designed to promote quicker and easier adoption of DTK.  So opt-ing in seems a bit anti ease of use and so it was decided that they would just be on.
> 
> I also think that non-async aware code "just to find errors" seems a bit of a backward step.  Dealing with exposing async errors properly would seem a more logical path forward.
> 
> On 4 June 2012 22:48, Mike Wilcox <mike at mikewilcox.net> wrote:
> As it is currently set up, the parser defaults to async. There is no opt in or opt out.
> 
> By default, it should parse sync. Then a dev doesn't have to figure out where his errors went. If he opts into async, then things are different.
> 
> Mike Wilcox
> http://clubajax.org
> mike at mikewilcox.net
> 
> 
> 
> On Jun 4, 2012, at 4:39 PM, Bill Keese wrote:
> 
>> I guess that depends what you mean by "catch".   We could add a console.error() by default, but it the application actually wants to catch the error and handle it, and the parser is running asynchronously, then the application would need to register an errback, just like for any other asynchronous operation (ex: an XHR).
>> 
>> On Tue, Jun 5, 2012 at 6:32 AM, Mike Wilcox <mike at mikewilcox.net> wrote:
>> Bill, you're not suggesting that the dev needs to attach error handlers to the parser to catch syntax errors, are you?
>> 
>> Mike
>> 
>> 
>> On Jun 4, 2012, at 4:05 PM, Bill Keese wrote:
>> 
>>> I don't really understand the question though; it seems like we don't need to do anything, that it's the app's responsibility to add an errback listener to the Promise.
>> 
>> 
>> _______________________________________________
>> dojo-contributors mailing list
>> dojo-contributors at mail.dojotoolkit.org
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>> 
>> 
>> _______________________________________________
>> dojo-contributors mailing list
>> dojo-contributors at mail.dojotoolkit.org
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> 
> 
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> 
> 
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120605/944930f3/attachment-0001.htm 


More information about the dojo-contributors mailing list