NotSupportedError contains a str, not a cx_Oracle._Error object

[stuffybell]

When I follow the docs' guidance on exception handling, a NotSupportedError contains a string, not the expected cx_Oracle._Error object. Below is a short script that reproduces the issue. I'm using a dict as an example variable, but any unsupported variable type will throw this error.

from __future__ import print_function
import cx_Oracle

connection = cx_Oracle.Connection("cx_Oracle/dev@localhost/orcl")
cursor = connection.cursor()

my_dict = {"foo": 1, "bar": 2}

try:
    stmt = cursor.prepare("SELECT dummy FROM dual WHERE dummy = :myvar")
    cursor.execute(stmt, {"myvar": my_dict})

except cx_Oracle.DatabaseError as exc:
    print(str(type(exc)))                      # <class 'cx_Oracle.NotSupportedError'>
    print(repr(exc))                           # NotSupportedError('Variable_TypeByValue(): unhandled data type dict',)
    error, = exc.args                          # "error" is a str, NOT a cx_Oracle._Error object
    print("Oracle-Error-Code:", error.code)    # AttributeError: 'str' object has no attribute 'code'
    print("Oracle-Error-Message:", error.message)

The documentation states:

With cx_Oracle every exception object has exactly one argument in the args tuple. This argument is a cx_Oracle._Error object...

Environment

• Python: 2.7.13 |Anaconda 4.3.1 (64-bit)
• cx_Oracle: 5.2.1
• Oracle client version: InstantClient 12.2 via rpm
• Oracle database version: 12.2
• OS: CentOS release 6.9 (Final)

[anthony-tuininga]

Thanks for pointing out the discrepancy between the documentation and the code. We'll address this. I'm leaning towards creating a cx_Oracle._Error object, even though some of the information in it will require default values. Is that what you would prefer, too?

[stuffybell]

Personally I would prefer that, just so all exceptions can be handled the same way. But I'm open to reasons why this is not desired. One I'm guessing you're alluding to is that the ".code" and ".message" properties would not correspond to an actual Oracle error message. Anyone else have any strong opinions?

[anthony-tuininga]

I have now implemented your suggestion. Thanks!

[stuffybell]

Thank you! Keep up the good work.