Cover error handling: exceptions, try/catch, and when to throw

[abdishakoor-dev]

Which module(s) and week(s) does this change affect?
Module(s): ITP, earlier than Data Flows (e.g. Structuring Data or Data Groups), plus Data Flows Sprint 3 for the async follow-up
Week(s): To be decided

What is the work that needs to be done?

We want to properly cover error handling:

• What exceptions are and what happens when one goes unhandled
• What try/catch is and how to use it
• When you should throw vs handle the error another way (return a value, log, recover, re-throw)
• How to handle errors well: catching at the right level, not swallowing errors, giving users/callers useful information

There is an existing block, common-content/en/module/js3/catch, which covers try/catch around async fetch calls. It was deliberately removed from Data Flows Sprint 3 prep in 4f8508c (#1111), with this rationale in the commit message:

1. We haven't actually taught try-catch anywhere, so we can't just rely on transferring "it's the same as you already know, just async".
2. There are already way too many novel concepts in Data Flows Sprint 3, and it's already very hard to follow from scratch.

If we add try-catch earlier in the course (which I think we should), we should re-add this.

So the work is likely two parts:

1. Introduce error handling fundamentals earlier in the course, in a synchronous context
2. Re-add the js3/catch block (or an updated version) to Data Flows Sprint 3, building on that foundation

Why is this work important to do?

Trainees currently learn fetch, promises, and async/await without ever being taught what to do when things fail. The removal in #1111 was explicitly conditional on teaching this earlier, which hasn't happened yet.

Who might need to know about this change?

@illicitonion

[jyothikiran09]

I support introducing error handling earlier in the curriculum.

Learning fetch, Promises, and async/await without first understanding exceptions and try...catch makes it difficult for learners to know how to respond when something goes wrong. Teaching the fundamentals first would make the later asynchronous concepts much easier to understand.

I suggest covering:

• What exceptions are and what happens when they are unhandled.
• How to use try...catch with simple synchronous examples.
• When to throw an error versus returning a value, logging the error, recovering from it, or re-throwing it.
• Good error-handling practices, such as catching errors at the appropriate level, avoiding swallowed errors, and providing meaningful error messages.

Once these concepts are introduced earlier, the existing async try...catch content in Data Flows Sprint 3 can be reintroduced as a natural continuation rather than as a completely new concept.

Overall, this change would provide learners with a stronger foundation and improve their confidence when working with asynchronous JavaScript.

[abdishakoor-dev]

@jyothikiran09 please take a look at the PR I raised linked in the timeline of this issue.