STOP DOING THIS:
// If anything goes wrong, do nothing.
// Don’t log anything.
// Don’t output anything.
// Suppress any sign of the problem.
// Just continue as if everything’s completely okay.
// Also, don’t actually write a comment here.
Let me explain why this is wrong.
Consider three reference points on the spectrum of errors that might occur in a build system:
- The build system broke (we’ll call this “fatal”): the makefile has a bug, a file resource disappeared, a gremlin burrowed through the ram
- A critical build task failed (“error”): the coffeescript has a syntax error, the server couldn’t start
- A validation task failed (“warning): the sass has a lint warning, a behavior test failed
Should the build fail for each of these error types? That depends on the context:
- In a CI server, everything down to a validation warning should result in a failed build
- In a watch / live-reload context, errors and warnings should be logged but the build should keep (continually) running
- In a one-off local development build, the “fatal” and “error” levels should cancel the build but a “warning” should not (well, a TDD developer would disagree)
How can these error permutations be handled in a gulp build? (more…)