This is the start to revisiting concepts taught in activity 3. it's a followup of merged pr #18 I will bring several comments over from @ucodery
encourage the fail fast approach to checks.
Raise errors with useful messages rather than using print statements. Print statements will allow the program to continue to run vs raising the error properly so this will avoid failing quietly and encourage fast fails.
We want to make sure that most of the lesson content is in the lesson rather than the activity but we can then link to it in the activity.
Two suggestions I have for this lesson:
encourage attendees to "fail fast"
only when it is unrecoverable
this makes the failure happen earlier, wasting less time waiting
this can make the stack trace more useful, as it points the the code experiencing the error
clearly describe the error.
rather than just printing out "exiting now", try to tell the caller why it was a mistake, and what they could maybe do to fix it.
maybe also explain that exceptions can (most of the time) take a message string, and it doesn't have to be printed also.
This is the start to revisiting concepts taught in activity 3. it's a followup of merged pr #18 I will bring several comments over from @ucodery
We want to make sure that most of the lesson content is in the lesson rather than the activity but we can then link to it in the activity.
also - this is the example provided around failing fast
I think this content could be a single workshop or even a day or two of programming on its own, but we will keep it high-level.