Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community!

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Python Practice Creating and Using Functions in Python Practice Functions Thank You!

I feel like I could use about 20 more exercises like this. I still don't really understand when to use "as err" vs not.

Sometimes we just use "raise ErrorType" and sometimes we "use except ValueError as err:" Both were used in the tickets project and in the functions exercise but I still don't understand when to use one vs the other and why.

2 Answers

Chris Freeman
Chris Freeman
Treehouse Moderator 68,404 Points

hey clion, good question! There some mechanisms of raising errors that aren’t obvious.

TL;DR: the as err is only needed if you want to access the error string associated in the error


  • when an error is raise’d, the argument is an instantiation of the error type
  • ValueError is a class. With parens, it returns an instance of the class. The string is an argument and becomes an attribute to the error instance
  • the except compares the raised error instance to the class type listed
  • the as err or as e or as label means if the error instance is of the listed error type, then use the label as a reference to the error instance. This as is basically an aliasing in the same way as is used on import statements
  • using this defined label reference, you may now reference the error string by using the label in a string context such as print(err). The error instance __str__ method simply prints out the args present at error instantiation

Post back if you need more help. Good luck!!!

David Hernandez
.a{fill-rule:evenodd;}techdegree seal-36
David Hernandez
Python Development Techdegree Graduate 12,180 Points

Hi clion, I feel ya when it comes to wanting to find the good pattern to help out make a decision. Much like the computers we use, ambiguity can cause challenges, where as discrete interpretations help things run smoothly. One way to view this is through the lens in which we read the statement: "Twitter can adjust" or something to that extent. From this, we see that we don't know the exact length, or that the length can change at any time. In this instance, we want to create a linear flow path and leave it that twitter has a raise exception for the length in the twitter function, and we are borrowing the twitter function. Given this, we want to go about the catch exception approach. If we are writing a function, or we are in control of some value, then we can create the raise. I hope that helps a bit.

Next, we have the application of the "err" part. So sometimes we want to override what the jargon says from the original exception, or we may want to add in our own context mixed in with it. So in this example we want to add in our own message plus theirs, so we use something like interpolation calling on the err to bring in the Error handling's message.