Why are Exceptions iterable? - exception

I have been bitten by something unexpected recently. I wanted to make something like that:
try :
thing.merge(iterable) # this is an iterable so I add it to the list
except TypeError :
thing.append(iterable) # this is not iterable, so I add it
Well, It was working fine until I passed an object inheriting from Exception which was supposed to be added.
Unfortunetly, an Exception is iterable. The following code does not raise any TypeError:
for x in Exception() :
print 1
Does anybody know why?

Note that what is happening is not related to any kind of implicit string conversion etc, but because the Exception class implements __getitem__ to return the values from the args tuple (ex.args). You can see this by the fact that you get the whole string as your first and only item in the iteration, rather than the character-by-character result you'd get if you iterate over the string.
This surprised me too, but thinking about it, I'm guessing it is for backwards compatibility reasons. Python used to (pre-1.5) lack the current class hierarchy of exceptions. Instead, strings were thrown, with (usually) a tuple argument for any details that should be passed to the handling block, i.e:
try:
raise "something failed", (42, "some other details")
except "something failed", args:
errCode, msg = args
print "something failed. error code %d: %s" % (errCode, msg)
It looks like this behavior was put in to avoid breaking pre-1.5 code expecting a tuple of arguments, rather than a non-iterable exception object. There are a couple of examples of this with IOError in the Fatal Breakage section of the above link
String exceptions have been deprecated for a while, and are gone in Python 3. Exception objects are no longer iterable in Python 3:
>>> list(Exception("test"))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'Exception' object is not iterable

NOT VALID. Check Brian anwser.
Ok, I just got it :
for x in Exception("test") :
print x
....:
....:
test
Don't bother ;-)
Anyway, it's good to know.
EDIT : looking to the comments, I feel like adding some explanations.
An exception contains a message you passed to during instantiation :
raise Exception("test")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
Exception: test
It's fair to say that the message is what defines the Exception the best, so str() returns it :
print Exception("test")
test
Now, it happens that Exceptions are implicitly converted to string when used in something else than an Exception context.
So when I do :
for x in Exception("test") :
print x
I am iterating over the string "test".
And when I do :
for x in Exception() :
print x
I do iterate over an empty string. Tricky. Because when it comes to my issue :
try :
thing.merge(ExceptionLikeObject)
except TypeError :
...
This won't raise anything since ExceptionLikeObject is considered as a string.
Well now, we know the HOW, but I still not the WHY. Maybe the built-in Exception inherit from the built-in String ? Because as far as I know :
adding str does not make any object iterable.
I bypassed the problem by overloding iter, making it raising TypeError !
Not a problem anymore, but still a mystery.

Related

catching classes that do not inherit from BaseException is not allowed

I'm making a custom plugin to query a database for user info to aide customer support. My backend is slack.
Everytime I start the bot command I'm greeted with:
Computer says nooo. See logs for details:
catching classes that do not inherit from BaseException is not allowed
I'm not sure if this is warning me that I'm attempting to catch an exception that isn't a BaseClass in my code or if an unknown exception was raised and caught elsewhere outside of my plugin.
To debug I tried:
try:
do_the_thing()
except (TypeError, ValueError) as e:
return('Something went wrong.')
I also tried:
try:
do_the_thing()
except Exception as e:
return('Something went wrong.')
And I still get the errbot admonition. Note that the command still runs and does the right thing where there is no exception raised by do_the_thing().
It means that:
Somewhere in your code you have an except ... statement where the exception ... (or one of the exceptions in the sequence ...) is not a subclass of BaseException, and
An exception is being thrown that is caught by that except ... statement.
The TypeError can be raised only when an exception is actually thrown because the names you give to except ... must be evaluated for their current values at that time; just because TypeError referenced a particular class at one point in the program's execution doesn't mean it won't be changed later to reference another object (though that would be admittedly perverse).
The Python interpreter should be giving you a full traceback of the exception; the first thing you need to do is find this. It could be occurring in one of two situations. (This is for single-threaded programs; I'm assuming your program is not multithreaded.)
During the execution of your program, in which case the program will be terminated by the exception, or
During finalization of objects (in their __del__(self) functions) in which case the error will be printed to stderr.
In both cases there should be a stack trace, not just the error message; I've confirmed that at least on Python ≥3.4 a stack trace is printed out for case 2.
You then need to follow this stack trace to see where the problem lies. Remember that the names you give to except ... are variables (even things like TypeError) that can be reassigned, so that you could conceivably be dealing with a (perverse) situation like:
TypeError = False
try:
...
except TypeError:
...
But more likely it will be something obvious such as:
class MyException: # Doesn't inherit from Exception
...
try:
...
except MyException:
...
There is one special case you need to be aware of: if you are seeing messages to stderr (case "2. During finalization," above) printed out as your program exits that means that the exception was thrown during cleanup as the interpreter shuts down, where random variables throughout the program may have already been set to None as part of the cleanup process. But in this case your program should still exit successfully.

2to3 bug: tuple index out of range, fix_raise

I have found what looks like a not tested case to me. When trying to convert following code with 2to3:
def test(arg):
raise()
The execution stops ungracefully with no indication why, nor what file caused the problem, this is very annoying if you are trying to convert a whole folder of python 2 scripts. The following is thrown:
...
exc= exc.children[1].children[0].clone()
IndexError: tuple out of range
I am expecting to obtain a BadInput exception. Clearly, given the source code just above, it is expecting raise("something") and since there is no check that "children" inside the tuple of raise () is even present, this causes error.
Please correct me if I am wrong, of course raise() is incorrect, but this should not crash the execution, likewise the following:
def test(arg):
print 1.method()
Throws BadInput exception with a clear indication what happened.

How long is a line after a readline(fh, line) call?

I have written a JSON parser in VHDL. The parser core uses two nested loops:
1. loop over all lines until EOF
2. loop over every char until line of end
For clearance: Its not a hardware parser. the parser used to read synthesis settings at synthesis time to configure instantiated entities like a baudrate in a UART module.)
The inner loop looks like this: loopj : for j in CurrentLine.all'range loop
Source: JSON.pkg.vhdl
This code works in XST 14.7, iSim 14.7 and GHDL, but not in Vivado. Vivado does not support .all. The error message is this one:
ERROR: [Synth 8-27] access type dereference not supported [D:/git/GitHub/JSON-for-VHDL/vhdl/JSON.pkg.vhdl:293]
Updated code, due to the hint from kraigher:
#Paebbles Have you tried foo'range instead of foo.all'range? I think I remember that it should implicitly work. - kraigher
I tried it before, but got an error. Maybe this error was related to another one. Now its working. So my current loopj line looks like this:
loopj : for j in CurrentLine'range loop
This line works fine in XST, iSim, GHDL and QuestaSim, but Vivado still has problems:
INFO: [Synth 8-638] synthesizing module 'Boards2' [.../Boards2.vhdl:16]
ERROR: [Synth 8-278] expression 0 out of range [.../JSON.pkg.vhdl:293]
ERROR: [Synth 8-421] mismatched array sizes in rhs and lhs of assignment [.../Boards2.vhdl:20]
ERROR: [Synth 8-285] failed synthesizing module 'Boards2' [.../Boards2.vhdl:16]
How can a expression be out of range? This message is very strange.
Is there another way to get a range for a loop, depending on how long the current line is?

Proper way to express application-specific exceptions

I'm trying to find a good way to express exceptions in dynamic-typed languages (e.g. Python, although the same code can be used with e.g. enums in static-typed languages). In my application, the exception is not going to be displayed to the user. Which one would be best? (or you can propose better)
def parseData(data):
length = unpack('!L', data[0:4])
if 4 + len(data) != length:
Option 1:
raise Exception("Invalid length")
Option 2:
return -1
# Some code later...
parseResult = parseData(data)
if validationResult == -1:
# Do something with the error.
The point is that when user doesn't see the exception, is it worth the hassle of making custom exception types instead of coming the easy path and returning integer values? (this is often done in functions like .indexOf(...)).
I can only comment on Python, but I would only extremely rarely raise Exception, as it makes error handling much harder; except Exception would catch many legitimate errors I would much rather hear about.
Instead, I would raise something more meaningful from the built-in exceptions:
raise ValueError("Invalid length.")
Most of Python's built-in classes and functions would raise an exception rather than returning some flag value. The only exception I can immediately think of is str.find, which will return -1 if the sub-string can't be found (its partner str.index will raise ValueError; I find this preferable, as -1 is a valid index).
There may be the occasional case where a single function could raise one of a range of exceptions, depending on what exactly has happened, but this is unusual - if your response will depend on what went wrong, that logic should probably be inside the function. You can still stick to the built-ins, for example:
def divide(n, lst, index):
return n / lst[index]
could raise TypeError, IndexError or ZeroDivisionError, and I can deal with that accordingly:
try:
divide(1, {3: 4, 5: 6}, 2)
except TypeError:
...
except IndexError:
...
except ZeroDivisionError:
...
except Exception as e:
print("Didn't see that coming: {0}".format(repr(e)))
You can even inspect the message in the exception to differentiate, if necessary:
def test():
test()
try:
test()
except RuntimeError as e:
if "recursion" in e.args[0]
print("Ran out of stack.")
else:
print("That was unexpected: {0}".format(repr(e)))

Python - pythoncom.com_error handling in Python 3.2.2

I am using Python 3.2.2, and building a Tkinter interface to do some Active Directory updating. I am having trouble trying to handle pythoncom.com_error exceptions.
I grabbed some code from here:
http://code.activestate.com/recipes/303345-create-an-account-in-ms-active-directory/
However, I use the following (straight from the above site) handle the exceptions raised:
except pythoncom.com_error,(hr,msg,exc,arg):
This code is consistent with many of the sites I have seen that handle these exceptions, however with Python 3.2.2, I get a syntax error if I include the comma after "pythoncom.com_error". If I remove the comma, the program starts, but then when the exception is raised, I get other exceptions because "hr", "msg" etc are not defined as global variables.
If I remove the comma and all of the bits in the brackets, then it all works well, except I can't see exactly what happens in the exception, which I want so I can pass through the actual error message from AD.
Does anyone know how to handle these pythoncom exceptions properly in Python 3.2.2?
Thanks in advance!
You simply need to use the modern except-as syntax, I think:
import pythoncom
import win32com
import win32com.client
location = 'fred'
try:
ad_obj=win32com.client.GetObject(location)
except pythoncom.com_error as error:
print (error)
print (vars(error))
print (error.args)
hr,msg,exc,arg = error.args
which produces
(-2147221020, 'Invalid syntax', None, None)
{'excepinfo': None, 'hresult': -2147221020, 'strerror': 'Invalid syntax', 'argerror': None}
(-2147221020, 'Invalid syntax', None, None)
for me [although I'm never sure whether the args order is really what it looks like, so I'd probably refer to the keys explicitly; someone else may know for sure.]
I use this structure (Python 3.5) --
try:
...
except Exception as e:
print ("error in level argument", e)
...
else:
...