Introduce try/catch in JS2W4

[illicitonion]

Which module(s) and week(s) does this change affect?
Module(s): JS2
Week(s): 4

What is the work that needs to be done?

A couple of things I'd really like us to focus on when introducing error handling are:

1. When and how you should throw errors - we've seen patterns like trainees returning strings containing error messages when things aren't as they expect - knowing they should be throwing is important.
2. That some errors are handle-able and others are fatal. Sometimes there's a sensible default to use if a conversion couldn't happen, or something can be retried, but other times the only thing to do when you hit an error is to give up.
3. That when something goes wrong, it should be reported to the user. Most of our trainees, if they do plan for errors, just console.log or console.error them - this isn't user-facing, and doesn't tell a user that something went wrong or what they should do about it.
4. What level of detail is useful to tell to whom in an error message being presented to a user.

We should do this in anticipation of JS3 where fetch introduces potentially transient errors outside of the trainees' control.

Why is this work important to do?

We don't really cover error handling in the curriculum at the moment. We happen to bring in try/catch around fetch time, but without really talking about it. This leads to our trainees either writing code which doesn't work if errors were encountered, or handling errors in ways which make their site look more broken or slow to users than it really is.

[illicitonion]

From #484 (comment) - maybe we want to introduce try/catch in JS2W3 through prep and a workshop, and then introduce the "how to surface errors in UI" and "think about what to actually show users" pieces in JS3W4 when trainees may actually encounter errors in the wild via fetch.

[illicitonion]

Note: Some of the exercises in Structuring And Testing Data Sprint 3 assume you know how to throw an error.