Empty Catch Blocks

Strong Bad

STOP DOING THIS:

[code language=”csharp”]
void ButtonClicked()
{
try
{
SaveEverything();
SubmitMonetaryTransaction();
SendConfirmationEmail();
}
catch
{
// 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.
}
}
[/code]

Let me explain why this is wrong.

(more…)

Error Handling in gulp

Photo of inside fo tackle box by Harrison Kugler on Unsplash

Consider three reference points on the spectrum of errors that might occur in a build system:

  1. The build system broke (we’ll call this “fatal”): the makefile has a bug, a file resource disappeared, a gremlin burrowed through the ram
  2. A critical build task failed (“error”): the coffeescript has a syntax error, the server couldn’t start
  3. 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…)