Refinements on exception handling - notes, chaining, and etc.

[sneakers-the-rat]

Reading through this lesson, and i am reminded of this problem i'm dealing with currently where pydantic truncates the traceback (for a different reason, because the exception happens in rust, but the structure of the problem is the same), and wanting to balance setting up our students to avoid footguns in the future while not overwhelming them with complexity.

In general it's good to avoid totally breaking exception chains unless they are for sure base python exceptions from builtins that everyone would be familiar with because you might obscure information from deeper in the chain (and you also don't have to repeat the information in the exception). Instead if you want to add information to an exception you can use add_note .

So while I was adding that change, i noticed a few other things that seemed related and so i changed a lot more text than i intended to here. ignore this and we can handle it after the fall festival if we're too close for this big of a change.

• Noticed that the example of breaking exception chains in lines 106-126 was redundant with the explanation that happens later, so omitted it and added a note highlighting why you included the type that caused the exception in its place
• added a footnote linking to the python tutorial when introducing the syntax
• I was putting myself in the POV of a student and feeling like i might be a little confused in the fail fast section, like "hang on, at first it seemed like i should always catch exceptions, because no errors, but now it seems like i should never catch errors and always raise them?" and felt like we needed a bit of discussion/examples on when to raise and when to catch, and how "fail fast" can work in practice in a circumstance where you want to catch some and raise other exceptions.
  • Tried to keep it simple by using the "process many folders of data with my custom functions, some of which may fail, but i want to go home and eat dinner and come back in the morning and have most of them be completed" example that the students are likely to be familiar with/encounter early in their programming career.
  • Also added an example of catching and using an exception with except Exception as e
  • I also added an example of raising a new exception in a context where we didn't just catch, bc otherwise it might seem like the only reason to catch and raise is to modify the message (which is an important case! just trying to round out examples)
• Split the "customizing error messages" into two sections, one for breaking chains and one for adding notes, and a little discussion on when we might do either.

I also added rich to pretty print the dictionary, and also because i love rich and i always use it in docs

[lwasser]

@sneakers-the-rat let's merge this as is.

i noticed a weird intro (that i missed fixing) in the rendered page and i do like what you've added.

NEW ISSUE: I think we need to explain what exception chaining is in this lesson. I can make a graphic for it. i'll open the issue now. and then merge this.