[dojo-contributors] Async Errors...

Kitson Kelly kitson.kelly at asseverate.co.uk
Tue Jun 5 16:36:21 EDT 2012


That makes sense.  Again, I agree that swallowing errors is bad (very bad)
and I should have thought of it to begin with.  It was in the back of my
mind nagging away and you brought it to the front.

I will take another look at the dojo/promise and how it is handling errors
since that seems to be the most favourable at the moment, although I do
think there is the bigger DTK question of a consistent way of dealing with
async errors for DTK (and it maybe just leveraging the dojo/promise API).

On 5 June 2012 16:51, Mike Wilcox <mike at mikewilcox.net> wrote:

> 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
>
>
>
> _______________________________________________
> 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/ee68d678/attachment-0001.htm 


More information about the dojo-contributors mailing list