For sure! I personally really like Typescript for minimizing those kinds of errors - this code was actually originally written with type annotations, but I removed them for the article because I thought they might be confusing.
But yes, you do make a good point - for something like a misspelling, hopefully I've written unit tests to catch that! In production code, I'd have some kind of error monitoring library like Honeybadger or Bugsnag to let me know when an error occurs or reaches a certain threshold. This code definitely still has the potential to run into errors, but that way I'll at least be alerted.
Yeah, I'm a bit weary of Promises because they catch all and any errors that might happen in the rejection branch and it's hard to discriminate whether it's an error that should or shouldn't happen. That's why I switched to using Futures a while ago. You still could map the rejection branch to a default value like you suggest, but it won't mask errors that it shouldn't handle.
I was curious to see what kind of difficulties you had encountered with that, hence my question :)
Oh, my co-worker is super into futures - he keeps pressing me to try them out. They look really interesting! Yeah, that part of Promises gets annoying; we've been having some discussions about when/what/where to catch and what to do then.
For sure! I personally really like Typescript for minimizing those kinds of errors - this code was actually originally written with type annotations, but I removed them for the article because I thought they might be confusing.
But yes, you do make a good point - for something like a misspelling, hopefully I've written unit tests to catch that! In production code, I'd have some kind of error monitoring library like Honeybadger or Bugsnag to let me know when an error occurs or reaches a certain threshold. This code definitely still has the potential to run into errors, but that way I'll at least be alerted.
Yeah, I'm a bit weary of Promises because they catch all and any errors that might happen in the rejection branch and it's hard to discriminate whether it's an error that should or shouldn't happen. That's why I switched to using Futures a while ago. You still could map the rejection branch to a default value like you suggest, but it won't mask errors that it shouldn't handle.
I was curious to see what kind of difficulties you had encountered with that, hence my question :)
Oh, my co-worker is super into futures - he keeps pressing me to try them out. They look really interesting! Yeah, that part of Promises gets annoying; we've been having some discussions about when/what/where to catch and what to do then.
That makes sense