Re: [Sqlalchemy-tickets] [sqlalchemy] #2361: Clarify vague error from within DDLCompiler.visit_create_table

[sqlalchemy <mi...@zz...>]

#2361: Clarify vague error from within DDLCompiler.visit_create_table
----------------------------------+------------------------------------
      Reporter:  bitmonk          |      Owner:  zzzeek
          Type:  defect           |     Status:  new
      Priority:  medium           |  Milestone:
     Component:  sql              |   Severity:  no triage selected yet
    Resolution:                   |   Keywords:
Progress State:  awaiting triage  |
----------------------------------+------------------------------------

Comment (by zzzeek):

 Patches like these often give me a bad taste, since they are trying to
 take one very specific case where there's an unideal stack trace and add
 particular contextual information - but there's many other places where
 this same trace (such as in compiling a `cast()`), as well as other
 similar ones (any number of conditions that fail on the database side, for
 example), can be raised, where this information is not available.  Getting
 it in one place is not really a substitute for the developer being able to
 use `pdb.post_mortem()`, climb up the stack, and see the source of an
 error.

 The exceptions raised directly within `MySQLTypeCompiler` should probably
 also be `CompileError` instances.   It feels a little more appropriate for
 `CompilerError` to be caught and re-raised with more information rather
 than totally changing the type of exception being emitted.   That way the
 originator of the exception can make the choice that this exception is
 appropriate for being "contextualized" and I'd feel like this patch is not
 quite so arbitrary.

 Another decision to be made is the mechanics of the re-raise.  This is the
 standard approach to a re-raise is:

 {{{
 except SomeException, e:
     # Py3K
     #raise NewException("message:" + str(e)) from e
     # Py2K
     raise NewException("message:" + str(e)), None, sys.exc_info()[2]
     # end Py2K
 }}}

 that at least preserves the original stack trace and in the case of Py3K
 provides both stack traces.

-- 
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2361#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python