Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#13297 closed defect (fixed)

better error reporting for loader failures

Reported by: Adam Peller Owned by: Rawld Gill
Priority: high Milestone: 1.7
Component: Loader Version: 1.7.0b1
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by Adam Peller)

In dojo.js, in the injectModule code around line , errors are handled in a finally clause

                                                try{
                                                        getText(url, legacyMode!=sync, xhrCallback);
                                                        ok = 1;
                                                }finally{
                                                        !ok && signal(errorListeners, [makeErrorToken("xhrFailed"), module]);
                                                }

could we catch the error instead (rethrow, if necessary) and capture e.message (perhaps some hint of the failure, like a parse failure) and have the error ultimately reported to the console with as much information as possible -- module which failed, its path, etc.? Right now, I think a raw Object gets dumped to the console.

Change History (5)

comment:1 Changed 8 years ago by Adam Peller

Description: modified (diff)

comment:2 Changed 8 years ago by Adam Peller

ok, I'm starting to get it... at first I thought there was a syntax error in the eval (synch loader) but now I'm thinking it was an internal loader error and the message really wasn't meant for public consumption. Feel free to close.

comment:3 Changed 8 years ago by Rawld Gill

I'll keep this open and investigate further.

Background: Until about [25542], the loader was configurable about whether it would catch versus not catch. But, with many browsers, catching made detecting some errors more difficult. otoh, removing all protection can put the loader in an unrecoverable error state. In short, the problem of detecting/reporting/recovering from programming and/or syntax errors in user modules is non-trivial and there are trade offs.

comment:4 Changed 8 years ago by Rawld Gill

Resolution: fixed
Status: newclosed

All try-catch paths removed by default as of [25926].

Reverted to the design that brackets all try-catch blocks in the loader with the has feature "config-dojo-loader-catches". config-dojo-loader-catches is false by default. Generally, it's intended to be used as a build switch to make a smaller loader and a loader that is guaranteed to remain in a legal state even when user modules throw exceptions. Note that if an exception escapes the loader, it is almost-certain that the loader will not be able to recover without help. Perhaps we should add a reset() API...but I'm not sure of the value of that yet.

comment:5 Changed 8 years ago by bill

Milestone: tbd1.7
Note: See TracTickets for help on using tickets.