Don't wrap loaders in a try/catch-block

[jhnns]

If a loader decides to throw an error, I think it's better not to catch the error within webpack. A loader error is critical and should be reported immediately to the the developer.

[sokra]

It is reported in the errors member of the resulting stats or in red on command line.
You can throw an exception if you want to.

if(stats.errors.length > 0) {
  throw new Error(stats.errors.join("\n"));
}

You even get multiple errors reported each with a stack trace... :)

[jhnns]

I've thought about this quite a while. I understand your concerns why you think it's better to collect errors.

But as the bundling is a critical process you can't just proceed if an error occurs. While I was developing it never occurred to me that there was an ignorable error. If an error isn't ignorable it should be thrown so the developer knows that something went wrong. This only leads to situations where webpack-unexperienced developers ask themselves wtf is going on because they can't see any error.

[jhnns]

Can a bundle be used regardless if an error occurred? I think you should not catch them.

[sokra]

Yes.

i. e. in this case

var module;
try {
  module = require("missing-module");
} catch(e) {
  module = require("replacement-module");
}

This would case an error while compiling, but the bundle can be used.

[jhnns]

If this code is within a module that I want to bundle, this would not cause an error because it is caught :). I don't know a situation where I might require a possible missing module without wrapping it within try-catch or using require.resolve before.

[sokra]

That is client side code, which cannot catch loader errors, which are thrown at compile time.

If I would throw an error if the missing-module is missing (or loader failed) that error would cause in "no bundle generated, because of error" and the client side code would never be executed, even if it could handle the missing module.

Therefore I decided to accept little errors (like missing modules, loader errors) and generate the bundle. On runtime there is an error thrown that a module is missing (like node.js would throw it). You can choose to accept some errors.

If you don't want to accept errors if(stats.errors[0]) throw stats.errors[0]; ;)

A nice reporting would be better. i.e. the (new) webpack-dev-server display the errors in the browser.

[jhnns]

Ok, now I get it. I was wrong, sorry.

However, I think webpack should not collect errors by default. I think it's much more usual to stop on every error. You may introduce an option like collectErrors. I've been experimenting with client-side bundlers for more than a year and I've never seen an error that can be ignored.

[sokra]

Maybe I'll change it for 0.7

I'll check than if a require call is in a try block and thead this cases only as warnings. Than all errors are critical and can be thrown. For watch mode there will be a new error type StoppingError which will be thrown if a error causes webpack's watch mode to stop.

Ideas