a native ImportError seems to me the best option and it's also easy to
polyfill in a meaningful way with all current module loaders used already
out there.
just my 2 cents
On Fri, Nov 21, 2014 at 3:10 AM, Isiah Meadows impinb...@gmail.com wrote:
Should we, then, throw a SyntaxError, a new
On Fri, Nov 21, 2014 at 11:49 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
a native ImportError seems to me the best option and it's also easy to
polyfill in a meaningful way with all current module loaders used already
out there.
My experience with AMD and require.js is that it
Traceur reports such errors like this:
// Error: File not found 'feature/Modules/resources/no_such_file.js'
// Error: Specified as ./resources/no_such_file.js.
// Error: Imported by
feature/Modules/Error_InvalidModuleDeclaration.module.js.
// Error: Normalizes to
to be honest I think that `.file` and `.line` would cover the who imported
what scenario but those look like a very good/complete `.message` for such
error, nice job
On Fri, Nov 21, 2014 at 3:37 PM, John Barton johnjbar...@google.com wrote:
Traceur reports such errors like this:
// Error:
At least using the older loader spec 'file' and 'line' alone is not enough
information for the loader to determine which file to load. I think the
error message should echo all of the information the developer would need
to recreate the error state and hopefully diagnose the issue. I agree that
if we have that and a very descriptive message then we won't need new
properties there but still I think having a different kind of instanceof
Error is helpful too. It's hard to guess through message parsing otherwise
;-)
On Fri, Nov 21, 2014 at 5:30 PM, John Barton johnjbar...@google.com wrote:
On Fri, Nov 21, 2014 at 6:39 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
if we have that and a very descriptive message then we won't need new
properties there but still I think having a different kind of instanceof
Error is helpful too. It's hard to guess through message parsing
Easy enough:
```js
class ImportError extends Error {}
```
Now, patching module loaders would be a whole different beast. For Node,
luckily, it's as simple as this, if turning it into a runtime error is
permissible (very similar for other cases):
```js
// original
import foo from ./module.js;
Should we, then, throw a SyntaxError, a new Error subclass created for the
purpose, since we don't have a dedicated Error class for it yet (e.g.
ImportError), or just a generic Error?
My thoughts about each option:
1. SyntaxError isn't relevant, since it's about a file that doesn't exist,
not an
What happens if a module isn't able to be found? Is that implementation
defined, or have I missed it in the spec?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
It should throw a static error, the loader is where this is specified I
believe, but it looks like the loader was pulled out into it's own spec
https://github.com/rwaldron/tc39-notes/blob/b1af70ec299e996a9f1e2e34746269fbbb835d7e/es6/2014-09/sept-25.md#loader-pipeline,
not sure where that ended up
On Nov 13, 2014, at 5:16 AM, Calvin Metcalf wrote:
It should throw a static error, the loader is where this is specified I
believe, but it looks like the loader was pulled out into it's own spec
12 matches
Mail list logo
