CodeSOD: Catch or Else

Today’s anonymous submitter asks a question: “How do you imagine the rest of the codebase to be like?”

Well, let’s look at this snippet of TypeScript and think about it:

.catch((): void => {
this.loadFromServerAndShowMessage();
});
} else {
this.loadFromServerAndShowMessage();
}
})
.catch((): void => {
this.loadFromServerAndShowMessage();
});
} else {
this.loadFromServer();
}
}

From the .catchs, I can tell that we’re looking at a series of nested promises, each loading content based on the results of the previous. The requests may fail in two ways- either through an exception (hence the catch calls), or because it doesn’t return useful data in some fashion (the else clauses).

Regardless of how it fails, we will loadFromServerAndShowMessage, which implies that we’re not expecting to handle failures based on connectivity. That seems like a mistake- if our promise fails for some reason, it’s likely because we don’t have connectivity, so loadFromServer doesn’t seem like a viable operation. Maybe we should look at the exception?

Nah, we don’t need to do that.

How do I imagine the rest of the code base? Well, I imagine it as a messy thicket of dependencies and no real modularity, fragile and confusing, and probably riddled with bugs, many of which are difficult or impossible to replicate in a controlled environment, meaning they’ll likely never get fixed.

Source: Read More