1

I'm working on a framework-like structure that uses curl.js as script loader. Modules can be located in either the App or Core directory, which allows me to override Core modules easily from the app. I had a server-side script to search these directories and return the first found file but then I decided that the client-side should be able to work without any help from backend, so now I have a function that tries listed directories until one of them has a file.

After a while I realized that I don't have any way to differentiate between 404 errors and syntax errors. I want the loader to fail if there is an actual error in code but in case of 404 it should just look for the next file and finally fail if no file can be found.

So, is it possible to detect if a script failed(in curl.js, AMD or generally in js) due to 404 and not because of errors in the loaded code?

jpeltoniemi
  • 5,320
  • 7
  • 24
  • 34

1 Answers1

0

Because of security concerns, browsers don't provide much information when scripts fail. In fact, IE refuses to even call the "load" event at all. The only information an AMD loader has is whether the define() was called or not.

There might be a way to detect some types of script errors, if you place your own global function call at the beginning of the script file. You can check if that function has been called. You can't detect SyntaxErrors that prevent parsing of the script, but you can detect other types of errors.

It might be possible to return the exact error to the errback function ( curl([]).then(callback, errback)) when the error happens while executing the factory function. Have you verified if this works or not?

unscriptable
  • 766
  • 6
  • 12
  • I ended up making a small php-based loader. Would you consider it bad practice to include GET parameters in module id? I have to include search paths in the module id (like `require(['fooModule?search=appModules,coreModules'])`). These modules are always loaded through the framework, so I can say for sure that the query strings are consistent and safe from typos. – jpeltoniemi Mar 07 '14 at 11:06
  • This sounds like a reasonable compromise that didn't take a lot of work. Glad you found a solution. – unscriptable Mar 10 '14 at 18:36