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! While you're at it, check out some resources Treehouse students have shared here.
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 trialclion
6,614 PointsI 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
Treehouse Moderator 68,457 Pointshey 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
Details:
- 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 classtype
listed - the
as err
oras e
oras label
means if the error instance is of the listed error type, then use the label as a reference to the error instance. Thisas
is basically an aliasing in the same wayas
is used onimport
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 theargs
present at error instantiation
Post back if you need more help. Good luck!!!
David Hernandez
Python Development Techdegree Graduate 12,180 PointsHi 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.