Catching exceptions that are not inherited from the exception

Question

I have a database access module that I call with a query or command. He determines what to do with the database, and tries to do it. But, for example, if the request or command line is pathological, a call to the PGDB base module may throw an exception.

Some incredibly useful information is returned by PGDB (from PostgreSQL at the same time), in particular, causing what errors were found in the query or command. This use of the various PGDB functions extracts this information:

try: pgdb.dothing(mod.withx) except Exception, e: mod.error = 'pgdb.dothing('+str(type(mod.withx))+str(mod.withx)+') failed with: '+str(e) 

Then, when the class returns, fails, the object contains a message in .error and viola, I can fix my stupidity in the request or command.

And all this works very well - (in Python 2.2.2, which may someday change to 2.higher ... but not now - and never, never 3. independently)

But ... I found this opacity bit: "the exception should not be inherited from Exception. So plain" except: "catches all exceptions, not just the system. String exceptions is one example of an exception that does not inherit from Exception "

So, the question is: Why does it bother me? If an exception occurs, I want to know why. I don't care where it came from, I just want an error message, and I'm sure Python doesn't want to stop. This will include if the error came from a string thing or something else. Therefore, in addition to catching everything is good. Or it should be.

Does this mean that the Exception parameter means that I will not catch the error if it comes from, for example, internal String strings? And then what, the code will stop with an uncaught exception? And then I need a series of catches for each type that "does not inherit from exception" to get the behavior I want? Something like that:

 try: pgdb.dothing(mod.withx) except Exception, e: mod.error = 'pgdb.dothing('+str(type(mod.withx))+str(mod.withx)+') failed with: '+str(e) except: mod.error = 'pgdb.dothing('+str(type(mod.withx))+str(mod.withx)+') failed with: WTF???' 

... because it really ... kind of sucks.

And if so, is there another way I can catch all exceptions of all types and get an error message for them? It seems like this would be very high, very desirable (and it also looks like a single liner should solve it, and it should look like a previous example, not the last).

Please answer before: Yes, I know Python 2.2.2 is deprecated. No, it will not be updated soon. It is a production system with several million lines of code; it is stable, and we want it to stay that way, based on "not broken, not fixing."

I just need a solid understanding of this part of the exclusion process that I’ve been beaten up. All the explanations seem to make assumptions about what I know, which are ... optimistic. :)

Thank you for understanding.

Answer 1

Try this, although this is bad practice. You should be as clear as possible when exceeding errors.

 try: ... except: e = sys.exc_info() print e 

I also suggest taking a look at https://wiki.python.org/moin/HandlingExceptions

Answer 2

Wow. It will take a little time to unpack some incorrect assumptions in this matter.

Catching everything is completely undesirable. How can it be? If an exception occurs, it is due to the fact that something went wrong. You cannot write code that deals with every mistake that may ever occur, simply because the code is not perfect. Thus, exceptions occur when unexpected errors occur, and you write processing code for those that you know you can handle.

But that still leaves things you can't handle: why do you catch them? What would you do if you caught them? It makes no sense to say that "I will simply register them and continue," because now your system is in an undefined state. Is this piece of data available? I do not know. Was it written in db? I can not tell. Have you just lost millions of revenue? Find me, guv.

As for the version of Python, if the fact that you are using a production system on an unsupported platform on which a large number of serious vulnerabilities were not only detected but actually exploited is not considered to be “broken,” I don’t know what it does.

Answer 3

Take a look at sys.exc_info() for the exception information in your simple execpt: .