feature: more detailed exceptions about pymssql

[GoogleCodeExporter]

Original comment by [email protected] on 8 Mar 2012 at 3:16

• Changed state: Accepted

[GoogleCodeExporter]

I took a stab at this that seems to work but needs more testing and review from 
some more eyes. This change adds more info to MSSQLDatabaseException:

http://code.google.com/r/msabramo-pymssql-issue41/source/detail?r=3d3d5934c2548d
24f83bdd9d01355ea585f11611

Sample usage:

vagrant@lucid64:~/dev/hg-repos/msabramo-pymssql-issue41$ .tox/py26/bin/python
issue_41_mssql.py
Traceback (most recent call last):
File "issue_41_mssql.py", line 11, in
charset='UTF-8')
File "_mssql.pyx", line 1658, in _mssql.connect (_mssql.c:17029)
return MSSQLConnection(_args, *_kwargs)
File "_mssql.pyx", line 519, in _mssql.MSSQLConnection.init (_mssql.c:5007)
maybe_raise_MSSQLDatabaseException(None)
File "_mssql.pyx", line 1398, in _mssql.maybe_raise_MSSQLDatabaseException (_mssql.c:13506)
raise ex
_mssql.MSSQLDatabaseException: DB: 'Unable to connect: Adaptive Server is
unavailable or does not exist', OS: 'Connection refused', tdscode: 20009,
tdsmsg: 'Net-Lib error during Connection refused'

I didn't do anything with `pymssql.OperationalError` yet, which is what gets 
thrown if you use `pymssql.connect` rather than _mssql.connect.

Original comment by [email protected] on 15 Jan 2013 at 3:51

[GoogleCodeExporter]

If I do:

vagrant@lucid64:~/dev/hg-repos/msabramo-pymssql-issue41$ hg diff
diff -r 3d3d5934c254 pymssql.pyx
--- a/pymssql.pyx Tue Jan 15 07:47:20 2013 -0800
+++ b/pymssql.pyx Tue Jan 15 08:10:08 2013 -0800
@@ -553,7 +553,7 @@
appname, port)

 except _mssql.MSSQLDatabaseException, e:

•    raise OperationalError(e[0])
  

•    raise OperationalError(e)
  

  except _mssql.MSSQLDriverException, e:
  raise InterfaceError(e[0])

then I get a nicer exception when `pymssql.connect` fails:

vagrant@lucid64:~/dev/hg-repos/msabramo-pymssql-issue41$ .tox/py26/bin/python
issue_41.py
Traceback (most recent call last):
File "issue_41.py", line 12, in
charset='UTF-8')
File "pymssql.pyx", line 556, in pymssql.connect (pymssql.c:7990)
raise OperationalError(e)
pymssql.OperationalError: DB: 'Unable to connect: Adaptive Server is
unavailable or does not exist', OS: 'Connection refused', tdscode: 20009,
tdsmsg: 'Net-Lib error during Connection refused'

but I don't understand what `e[0]` was doing, so not sure if it's OK to change 
it. If it is OK, then there are a bunch of places in `pymssql.pyx` that catch 
MSSQLDatabaseException and raise an OperationalError and perhaps these should 
be changed as well, but these are lot of hard-to-reproduce edge cases, so I'm 
not sure how to proceed.

Original comment by [email protected] on 15 Jan 2013 at 4:17

[GoogleCodeExporter]

Original comment by [email protected] on 7 Aug 2013 at 1:56

• Added labels: Type-Enhancement, patchincluded, needstesting
• Removed labels: Type-Defect

[GoogleCodeExporter]

> Traceback (most recent call last):
  File "issue_41.py", line 12, in <module>
    charset='UTF-8')
  File "pymssql.pyx", line 556, in pymssql.connect (pymssql.c:7990)
    raise OperationalError(e)
pymssql.OperationalError: DB: 'Unable to connect: Adaptive Server is 
unavailable or does not exist', OS: 'Connection refused', tdscode: 20009, 
tdsmsg: 'Net-Lib error during Connection refused'

but I don't understand what e[0] was doing, so not sure if it's OK to
change it.

From PEP 3110 and PEP 352 an exception instance could (before Python 3) be
accessed
by index. The values obtained were the ones passes when instantiaging/raising
it (if
any), in the same order.

So when pymssql.pyx catches MSSQLDatabaseException as e and the treats it
raising a pymssql-level exception with value e[0] it's actually passing to the
user
the two-element tuple with which maybe_raise_MSSQLDatabaseException() is
instantiating it:

MSSQLDatabaseException((get_last_msg_no(conn), get_last_msg_str(conn)))

The tuple is the one we are uded to see when dealing with pymssql/[Feee]TDS:

(20009, 'Net-Lib error during Connection refused')

Something similar (but simpler) happens when it catches MSSQLDriverException as
e,
raising a new exception with value e[0] simply makes the string reported by
_mssql.pyx bubble up to the user.

Original comment by `[email protected]` on 16 Aug 2013 at 10:37

[GoogleCodeExporter]

Original comment by [email protected] on 23 Sep 2013 at 10:06

• Removed labels: patchincluded

[GoogleCodeExporter]

Original comment by [email protected] on 23 Sep 2013 at 10:15

• Removed labels: needstesting