Introduce error handling and try/catch (probably in Data Groups?)

illicitonion commented 1 month ago

ITP currently doesn't introduce error handling. Both conceptually ("Think about something may go wrong, and do something about it") and practically ("try/catch/exceptions/throw").

This was originally a prereq of the Piscine. We'll skip over it for the first Piscine, but we'd like to re-add this as a prereq.

The "thinking about errors" piece is realistically more important than the practicality of try/catch etc. We want to be training people to be thinking about what can go wrong.

One flaw of how we've taught this in the past we'd like to avoid doing again is teaching catch (err) { console.error(err); } as a default action. I'd really like us to emphasise that if something goes wrong, either our code needs to work around it (e.g. with a retry), or we need to display something to the user. In the past a lot of our trainees have thought console.error is a valid way of telling a user something went wrong.

Data Groups probably has some spare time to throw in this extra topic, but open to discussion!

Dedekind561 commented 6 days ago

Hi there, so currently we talk about errors in 2 places that I can see so far:

SyntaxErrors in Structuring data in Sprint 1
ReferenceErrors (fleetingly) in the scope block of Structuring data in Sprint 1

In terms of error handling, the only thing I can think of at the moment is a situation where a function isn't passed the right type of argument. Can you think of anything else? @illicitonion

illicitonion commented 6 days ago

I would like our trainees to be able to handle the following situations:

Discussing the idea of input validation

When writing a function that, say, requires a non-empty string argument, I want our trainees to be able to identify "I would throw an exception if it's empty" as a possible strategy.

Throwing an error due to invalid input in a Codewars

If a Codewars problem says something like "If a caller passes an empty or non-string argument, throw an error" they know what this means. (I suspect there are sample Codewars which would do this, but I find it impossible to search Codewars problems :'()

Handling a runtime error

If writing code like:

await fetch("https://doesnotexist");

I would like our trainees to be able to write code like:

try {
  await fetch("https://doesnotexist");
} catch (e) {
  console.error(e);
  alert("There was a problem and here is some information about it");
}

Making sure the user is aware

In the past our trainees have typically written code like:

try {
  await fetch("https://doesnotexist");
} catch (e) {
  console.log(`An error occurred: ${e}`);
}

I would really like them to think "Real users don't look in the console, this isn't useful error reporting, I need to do something in the UI".

Stretch: Retriable errors

In a dream world, I'd like our trainees to think about what is potentially retriable without change (e.g. an HTTP 429/5xx response), retriable with modification (e.g. an HTTP 401 response), and what isn't (e.g. an HTTP 403 response, or a DNS lookup failure). But I suspect this is not a topic for ITP.

CodeYourFuture / curriculum