User-defined exceptions as ProgrammingError
What kind of database errors are ProgrammingError? If you raise a user-defined exception through the procedure raise_application_error, the cx_Oracle raising an DatabaseError.
I think is more clear use ProgrammingError for user-defined exceptions instead of DatabaseError.
with connection.cursor() as cursor:
try:
cursor.execute("begin raise_application_error(-20000, 'Sometime strange thins just happens'); end;")
except cx_Oracle.ProgrammingError as e:
print("Yes, you are busines validation error")
except cx_Oracle.DatabaseError as e:
print("Hey i'm not a business validation")
Python Version: 3.7.4 cx_Oracle Version: 7.2.2 oracleinstantclient Version: 12.2 Oracle server Version : 11g XE SO: Fedora 30
+1
ProgrammingError is only raised for errors like "positional and named binds cannot be intermixed". Almost all Oracle errors are raised as DatabaseError. There are some that are raised as IntegrityError and OperationalError. You can take a look at the source for the function cxoError_raiseFromInfo() for the details.
As for whether ORA-20000 should be defined as a ProgrammingError instead of DatabaseError, that's a matter for debate! I'm sure others might disagree with your evaluation and I'm not sure I'm convinced either. I'll ask @cjbj to give his opinion as well.
Another option would be to define a new exception named ApplicationError do deal with user-defined errors.
I don't think ProgrammingError makes sense for application runtime errors. ApplicationError might be nice, but is the backward compatibility break worth it?
If ApplicationError is subclass of DatabaseError, this will not break the backward compatibility.
True enough. If @cjbj has no objections I'll add it to cx_Oracle 8. It will cover the error numbers from -20000 to -20999.
8.3 doesn't have ApplicationError. Plan is valid to add it?
I don't see it in the next major version, so we'll have to revisit when we get a moment.