Explain what exception chains are

[lwasser]

In reading and following the evolution of our function checks lesson, it's clear to me that some of what we need to do is explain exception chaining at a very high level and create a visual for students to understand.

my experience teaching Python has been that students are totally overwhelmed by the volume of output that Python provides. And I think helping them understand what's happening at a high level could ease some of that anxiety and make the concepts around try/except blocks easier to absorb. This relates to the recently merged #72 by @sneakers-the-rat

[sneakers-the-rat]

Completely fair. I was trying to avoid a full explanation in that lesson because I figured we have limited time in the workshops and wouldn't want to spend it all on exception handling, and just gave a link to further docs for people who wanted to read more on their own time. Following your lead focusing more on "how do i make this do what i want it to" than understanding the system design in complete detail. But yes! ideally these lessons would be self-sufficient after the festival, so then adding in details would be great.

Might be better in an "advanced" lesson, because I think all the permutations of exception handling and chaining really only come into play when you're designing more complex systems or systems intended for downstream use where you would want to be specific about the types of errors you raise so someone can catch them. Otherwise catch -> handle; catch -> re-raise (eg. with added note) handle most common needs? I think what would be nice to have here is like a dedicated lesson that's just exception handling patterns with not exactly a "pro/con" list but a discussion on when you would use those patterns and when you wouldn't.

I think as far as examples go, data validation might be a good one? like i'm thinking of what i'm doing right now in numpydantic, and i need to catch a whole range of exceptions and transform them into a hierarchy of exceptions that then are chained beneath a pydantic ValidationError - so we both get feedback about what caused the error, but enclosing code is able to catch different kinds of errors in a predictable way rather than needing to catch all the kinds of errors that could happen. pydantic is also a case where you need to be careful about the kinds of errors that you raise because the framework you're in expects a specific error type, so it might be a decent, familiar example that covers a range of patterns on the raising and handling side with good motivations for chaining/not chaining/etc.

edit: Also side note see some of the discussion around the pydantic validation error here: pydantic/pydantic#7470 and surrounding issues that show the problems that happen when you have an exception type that doesn't chain well

[lwasser]

This sounds great @sneakers-the-rat Yes, let's wait until after the workshop. We have a fairly short period of time to cover this stuff during.

And i think our main goal for the workshop is really to raise awareness of adding logic and checks to code and how powerful it can be for users and developers / scientists processing data!
I like the idea of adding this content to our lessons after!!

[willingc]

Python 3.13 should improve much of the error understanding: https://docs.python.org/3/whatsnew/3.13.html#improved-error-messages