why my excepts are not executing?
def TestNumbers(x,y,z):
try:
X = int(x)
y = int(y)
z = int(z)
print(‘You have provided valid values’)
except NameError:
print('NameError')
except:
print("You have provided invalid inputs to the function")
if x == y and x == z:
return True
else:
return False
print(TestNumbers(a,6,7))
It is impossible to say because no way to determine indentation in your code.
However, if your indentation is correct your except execute. As a side note - I don’t understand what this code should accomplish.
If you are at it, maybe consider also using names according to Python convention,
PEP8 > Function and variable names:
Function names should be lowercase, with words separated by underscores as necessary to improve readability.
Variable names follow the same convention as function names.
mixedCase is allowed only in contexts where that’s already the prevailing style (e.g. threading.py), to retain backwards compatibility.
So instead of TestNumbers you could use test_numbers.
why my excepts are not executing?
They look ok to me. Maybe x, y and z are all valid strings representing
ints?
def TestNumbers(x,y,z):
try:
X = int(x)
y = int(y)
z = int(z)
print(‘You have provided valid values’)
BTW, I would put this print in the else part of the try/except:
try:
....
except NameError:
print("NameError")
except:
print("som other unspecified exception")
else:
print("You have provided valid values")
otherwise the try/except is also testing the “valid values” print().
Not normally what people intend.
print(TestNumbers(5,6,8))
These are valid ints: int(9) == 9
print(TestNumbers(“a”,5,8))
This should fire your second except: int(“a”) should raise a ValueError.
print(TestNumbers(a,6,7))
I don’t see a definition for the variable named “a”.
Note that the NameError this causes will happen before calling
TestNumbers, so the try/except won’t see it, as the try/except never
even runs.
Besides, you rarely want to catch NameError - it almost always indicates
an error in your programme logic, not invalid data to process.
Finally, it is almost always best to report the exception you catch (if
you don’t handle it):
try:
....
except NameError as e:
print("Name Error!", e)
That way you get some information about what, specificly, was bad.
And a “bare except”:
except:
is also usually a bad idea: it catches anything. Normal practice is to
catch only things for which you have a well defined action to recover
from. That way unexpected (and unhandled) exceptions get out and provide
a nice traceback showing how the code was called, which helps you debug
the situation.
Sometimes you need to catch more than you can handle. Example:
try:
f = open("filename")
except OSError as e:
if e.errno == errno.ENOENT:
print("missing file, but that is ok")
else:
raise
else:
process the file f here ...
Here we have a look at a broad class of error, and recognise a specific
special circumstance which is ok (missing file? pretend it is empty).
Otherwise we reraise the exception as though it had never been caught in
the “else:” part of the if-statement.
Cheers,
Cameron Simpson cs@cskk.id.au
For beginners struggling to get even the simplest thing right, or to get
their code to work, pushing them to use PEP-8 conventions is maybe not
so important.
Define so 
While I know that A Foolish Consistency is the Hobgoblin of Little Minds I strongly believe that there is need to teach beginners about conventions.
For me function name is in the same ballpark as 4 spaces and while using whatever number of spaces consistently doesn’t break the code it breaks the readability.
From first grade we teach how to write grammatically correct in natural language, why don’t we adopt similar approach to coding?
On personal note: I haven’t seen any decent course where introduction of functions does not cover naming convention (of course, my experience is limited)
Hi Aivar,
This is a sample of the expected standard for children’s sentences at
the end of first grade:
We don’t expect them to learn:
and many more concepts. Learning to code is a lot harder than learning
first year grammar.
Meaningful names is much more important than using an arbitrary naming
convention which is not mandatory outside of the stdlib.
There is nothing wrong with CamelCase names, or even all lowercase
names. So long as the names are meaningful and self-descriptive,
adherance to some in-house style (whether it is PEP 8 or some other
style) can come later. Let’s not make the learning process harder than
it needs to be by needless asthetic pedantry over style.
Thank you.