SQLAlchemy raises None, causes TypeError
Question: I'm using the declarative extension in SQLAlchemy, and I noticed a strange
error when I attempted to save an instance of a mapped class with incorrect
data (specifically a column declared with nullable=False with a value of
None).

The class (simplified):

    
    
    class User(Base):
        __tablename__ = 'users'
    
        id = Column(Integer, primary_key=True, autoincrement=True)
        userid = Column(String(50), unique=True, nullable=False)
    

Causing the error (session is a SQLAlchemy session):

    
    
    >>> u = User()
    >>> session.add(u)
    >>> session.commit()
    
    ...
    
    TypeError: exceptions must be old-style classes or derived from BaseException, not NoneType
    

Looking at the code that causes this exception, I found (in
sqlalchemy.orm.session):

    
    
    except:
        transaction.rollback(_capture_exception=True)
        raise
    

The exception being caught in this case is a sqlalchemy.exc.OperationalError.
If I change these lines to:

    
    
    except Exception as e:
        transaction.rollback(_capture_exception=True)
        raise e
    

then the problem goes away, and the OperationalError gets thrown instead of
None. Shouldn't the original code work in any recent version of Python though?
(I'm using 2.7.2) Is this error somehow specific to my application?

Python 2.7.2

SQLAlchemy 0.7.5

UPDATE: the error seems to be specific to my application in some way. I'm
wrapping an eventlet.db_pool with a SQLAlchemy engine, which appears to be the
source of the problem somehow. Running my simple test with either in-memory
SQLite or basic MySQL engine doesn't have this problem, but with the db_pool
it does.

Test case: <https://gist.github.com/1980584>

The full traceback is:

    
    
    Traceback (most recent call last):
      File "test_case_9525220.py", line 41, in <module>
        session.commit()
      File "/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 645, in commit
        self.transaction.commit()
      File "/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 313, in commit
        self._prepare_impl()
      File "/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 297, in _prepare_impl
        self.session.flush()
      File "/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 1547, in flush
        self._flush(objects)
      File "/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/sqlalchemy/orm/session.py", line 1635, in _flush
        raise
    TypeError: exceptions must be old-style classes or derived from BaseException, not NoneType
    


Answer: Here is what I've discovered:

  * The exception (an `OperationalError`) is ok until the failed transaction rolls back (in `Session._flush()`). 
  * The transaction rollback is handled by mysqldb through `eventlet.tpool`. Specifically, `eventlet.tpool.execute` is called, which involves creating an `eventlet.Event` and calling its `wait` method. 
  * While waiting, a few complicated thread-related things happen, one of is checking for an exception and passing it to the Event to handle. It picks up the `OperationalError` which is still in `sys.exc_type`, and ultimately clears it in `eventlet.event.hubs.hub.BaseHub.switch`.
  * Control returns to `Session._flush`, and the exception is re-raised (using `raise`), but at this point there is no exception so it tries to `raise None`.

This behaviour can be reproduced with a simple example:

    
    
    from eventlet import tpool
    
    def m(): 
        pass
    
    try:
        raise TypeError
    except:
        tpool.execute(m)
        raise
    

Its a bit unclear exactly what eventlet should be doing in this situation, so
I don't know whether the bug should be reported to sqlalchemy or eventlet, or
both.

The easiest way to rectify it is, as you've already noted, to change the last
few lines of `sqlalchemy.orm.session.Session._flush` from

    
    
        except Exception:
            transaction.rollback(_capture_exception=True)
            raise
    

to

    
    
        except Exception, e:
            transaction.rollback(_capture_exception=True)
            raise e
    

**Edit:** I have raised an
[issue](https://bitbucket.org/eventlet/eventlet/issue/118/exceptions-are-
cleared-during) on eventlet's issue tracker. It might be worth raising it on
sqlalchemy too though.

