Changes between Initial Version and Version 1 of Ticket #14222


Ignore:
Timestamp:
Nov 8, 2011, 12:22:33 AM (9 years ago)
Author:
Kenneth G. Franqueiro
Comment:

Marking this as tbd as it's unlikely to land in 1.6.x (since it doesn't sound like something that would be a 1.6-introduced regression). I'd be curious whether this same problem is reproducible on 1.7, given the new loader.

Moreover, not sure how much priority this will be given, given that a server returning a 200 in a 404 case certainly seems like invalid behavior beyond our control. The fact that it's causing further issue on FF7 is interesting though...

I am not a loader expert, but it seems to me that try/catching that line of code might hamper error reporting in cases where you really do want the loader to inform you of a problem when attempting to execute code in a loaded module, and I also can't imagine it'd be at all good from a performance standpoint either.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #14222

    • Property Keywords FF7 added; Firefox 7 removed
    • Property Milestone changed from 1.6.2 to tbd
  • Ticket #14222 – Description

    initial v1  
    1212
    1313Wrap this line (116 in 1.6.1) into a try/catch block:
     14
     15{{{
    1416        var value = d["eval"](contents);
     17}}}
    1518
    1619Could look like this:
    1720
     21{{{
    1822try{
    1923        var value = d["eval"](contents);
     
    2327        contents = null;
    2428}
     29}}}
    2530
    2631The loader is too central, so I cannot oversee the consequences of this change - I'm sorry that my resources are too limited to do further investigation, but I think, this enhancement would help a lot to make dojo more stable, as a certain webserver configuration would not make dojo to fail working.