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
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.
Chris FreemanTreehouse Moderator 68,404 Points
hey clion, good question! There some mechanisms of raising errors that aren’t obvious.
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
ValueErroris a class. With parens, it returns an instance of the class. The string is an argument and becomes an attribute to the error instance
exceptcompares the raised error instance to the class
as labelmeans if the error instance is of the listed error type, then use the label as a reference to the error instance. This
asis basically an aliasing in the same way
asis used on
- 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
argspresent at error instantiation
Post back if you need more help. Good luck!!!
David HernandezPython 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.