Initially I thought being as specific as possible is the best way to go about it:
from django.db import IntegrityError
from psycopg2.errorcodes import UNIQUE_VIOLATION
try:
m = Model.objects.create(value=m2.old_value)
except IntegrityError as e:
if e.__cause__.pgcode != UNIQUE_VIOLATION:
raise
m = Model.objects.get(value=m2.old_value)
However later I ran into the answer that says:
SQLAlchemy is an abstraction library and if it were to raise exceptions specific to the underlying dpapi adapter, it would significantly reduce the portability of code written within it.
...
However, unless your error handling is very specific to the type raised by the dbapi layer, I'd suggest that inspecting the underlying type might be unnecessary as the SQLAlchemy exception that is raised will provide enough runtime information to do what you have to do.
django.db.IntegrityError is supposedly raised in the following cases:
INTEGRITY_CONSTRAINT_VIOLATION = '23000'
RESTRICT_VIOLATION = '23001'
NOT_NULL_VIOLATION = '23502'
FOREIGN_KEY_VIOLATION = '23503'
UNIQUE_VIOLATION = '23505'
CHECK_VIOLATION = '23514'
EXCLUSION_VIOLATION = '23P01'
I'm not sure under which circumstances these particular errors occur, but the general rule is, "don't ignore exceptions." And if I choose:
try:
m = Model.objects.create(value=m2.old_value)
except IntegrityError as e:
m = Model.objects.get(value=m2.old_value)
It sounds like I might ignore an exception I didn't mean to ignore. What would you suggest?
I don't see any problem with doing what you're doing. There's certainly no reason not to add code to get a clearer idea of what kinds of errors get thrown and are catchable under various conditions. If you're not sure if this code is right as is, then it's better to be too specific rather than not specific enough. After you've run and tested your code for a while, you'll know more about the "correctness" of what you're doing here. Maybe you'll decide later to make a change. Maybe you'll decide that you can treat larger groups of exceptions in a similar way.
One important thought though... You' aren't ignoring any errors here. There's a difference between ignoring an error, which means doing nothing different when one occurs than when it does not, and catching an error and then doing something different because that error occurred. That's not ignoring the error at all, and that's what you're doing here. So the question here is "is doing a get under all cases where a create throws an IntegrityError exception the right thing to do?". If the answer is "No", then that's where you have to test for specific error conditions and decide if the right thing is to do a get or let the error propagate because something is really wrong. That's just what you're doing. If the code you present is doing that correctly, then maybe it's exactly what you want.
Bottom line...do whatever you have to do to get the code to act right in all cases. If doing that means digging into the exception the way you are, so be it.
I'm curious...what are your thoughts on not allowing an exception to be thrown at all? That is, what about checking for the pre-existence of the record before attempting the create? Is there a reason you can't do this? Also, what about reversing the two operations? Might it make sense to do the get first, and then do the create if that fails? I'm only presenting these other options to explore all the options here, both for your benefit and that of the question itself.
This is a hard question to phrase, but here's a stripped-down version of the situation. I'm using some library code that accepts a callback. It has its own error-handling, and raises an error if anything goes wrong while executing the callback.
class LibraryException(Exception):
pass
def library_function(callback, string):
try:
# (does other stuff here)
callback(string)
except:
raise LibraryException('The library code hit a problem.')
I'm using this code inside an input loop. I know of potential errors that could arise in my callback function, depending on values in the input. If that happens, I'd like to reprompt, after getting helpful feedback from its error message. I imagine it looking something like this:
class MyException(Exception):
pass
def my_callback(string):
raise MyException("Here's some specific info about my code hitting a problem.")
while True:
something = input('Enter something: ')
try:
library_function(my_callback, something)
except MyException as e:
print(e)
continue
Of course, this doesn't work, because MyException will be caught within library_function, which will raise its own (much less informative) Exception and halt the program.
The obvious thing to do would be to validate my input before calling library_function, but that's a circular problem, because parsing is what I'm using the library code for in the first place. (For the curious, it's Lark, but I don't think my question is specific enough to Lark to warrant cluttering it with all the specific details.)
One alternative would be to alter my code to catch any error (or at least the type of error the library generates), and directly print the inner error message:
def my_callback(string):
error_str = "Here's some specific info about my code hitting a problem."
print(error_str)
raise MyException(error_str)
while True:
something = input('Enter something: ')
try:
library_function(my_callback, something)
except LibraryException:
continue
But I see two issues with this. One is that I'm throwing a wide net, potentially catching and ignoring errors other than in the scope I'm aiming at. Beyond that, it just seems... inelegant, and unidiomatic, to print the error message, then throw the exception itself into the void. Plus the command line event loop is only for testing; eventually I plan to embed this in a GUI application, and without printed output, I'll still want to access and display the info about what went wrong.
What's the cleanest and most Pythonic way to achieve something like this?
There seems to be many ways to achieve what you want. Though, which one is more robust - I cannot find a clue about. I'll try to explain all the methods that seemed apparent to me. Perhaps you'll find one of them useful.
I'll be using the example code you provided to demonstrate these methods, here's a fresher on how it looks-
class MyException(Exception):
pass
def my_callback(string):
raise MyException("Here's some specific info about my code hitting a problem.")
def library_function(callback, string):
try:
# (does other stuff here)
callback(string)
except:
raise Exception('The library code hit a problem.')
The simplest approach - traceback.format_exc
import traceback
try:
library_function(my_callback, 'boo!')
except:
# NOTE: Remember to keep the `chain` parameter of `format_exc` set to `True` (default)
tb_info = traceback.format_exc()
This does not require much know-how about exceptions and stack traces themselves, nor does it require you to pass any special frame/traceback/exception to the library function. But look at what this returns (as in, the value of tb_info)-
'''
Traceback (most recent call last):
File "path/to/test.py", line 14, in library_function
callback(string)
File "path/to/test.py", line 9, in my_callback
raise MyException("Here's some specific info about my code hitting a problem.")
MyException: Here's some specific info about my code hitting a problem.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "path/to/test.py", line 19, in <module>
library_function(my_callback, 'boo!')
File "path/to/test.py", line 16, in library_function
raise Exception('The library code hit a problem.')
Exception: The library code hit a problem.
'''
That's a string, the same thing you'd see if you just let the exception happen without catching. Notice the exception chaining here, the exception at the top is the exception that happened prior to the exception at the bottom. You could parse out all the exception names-
import re
exception_list = re.findall(r'^(\w+): (\w+)', tb_info, flags=re.M)
With that, you'll get [('MyException', "Here's some specific info about my code hitting a problem"), ('Exception', 'The library code hit a problem')] in exception_list
Although this is the easiest way out, it's not very context aware. I mean, all you get are class names in string form. Regardless, if that is what suits your needs - I don't particularly see a problem with this.
The "robust" approach - recursing through __context__/__cause__
Python itself keeps track of the exception trace history, the exception currently at hand, the exception that caused this exception and so on. You can read about the intricate details of this concept in PEP 3134
Whether or not you go through the entirety of the PEP, I urge you to at least familiarize yourself with implicitly chained exceptions and explicitly chained exceptions. Perhaps this SO thread will be useful for that.
As a small refresher, raise ... from is for explicitly chaining exceptions. The method you show in your example, is implicit chaining
Now, you need to make a mental note - TracebackException#__cause__ is for explicitly chained exceptions and TracebackException#__context__ is for implicitly chained exceptions. Since your example uses implicit chaining, you can simply follow __context__ backwards and you'll reach MyException. In fact, since this is only one level of nesting, you'll reach it instantly!
import sys
import traceback
try:
library_function(my_callback, 'boo!')
except:
previous_exc = traceback.TracebackException(*sys.exc_info()).__context__
This first constructs the TracebackException from sys.exc_info. sys.exc_info returns a tuple of (exc_type, exc_value, exc_traceback) for the exception at hand (if any). Notice that those 3 values, in that specific order, are exactly what you need to construct TracebackException - so you can simply destructure it using * and pass it to the class constructor.
This returns a TracebackException object about the current exception. The exception that it is implicitly chained from is in __context__, the exception that it is explicitly chained from is in __cause__.
Note that both __cause__ and __context__ will return either a TracebackException object, or None (if you're at the end of the chain). This means, you can call __cause__/__context__ again on the return value and basically keep going till you reach the end of the chain.
Printing a TracebackException object just prints the message of the exception, if you want to get the class itself (the actual class, not a string), you can do .exc_type
print(previous_exc)
# prints "Here's some specific info about my code hitting a problem."
print(previous_exc.exc_type)
# prints <class '__main__.MyException'>
Here's an example of recursing through .__context__ and printing the types of all exceptions in the implicit chain. (You can do the same for .__cause__)
def classes_from_excs(exc: traceback.TracebackException):
print(exc.exc_type)
if not exc.__context__:
# chain exhausted
return
classes_from_excs(exc.__context__)
Let's use it!
try:
library_function(my_callback, 'boo!')
except:
classes_from_excs(traceback.TracebackException(*sys.exc_info()))
That will print-
<class 'Exception'>
<class '__main__.MyException'>
Once again, the point of this is to be context aware. Ideally, printing isn't the thing you'll want to do in a practical environment, you have the class objects themselves on your hands, with all the info!
NOTE: For implicitly chained exceptions, if an exception is explicitly suppressed, it'll be a bad day trying to recover the chain - regardless, you might give __supressed_context__ a shot.
The painful way - walking through traceback.walk_tb
This is probably the closest you can get to the low level stuff of exception handling. If you want to capture entire frames of information instead of just the exception classes and messages and such, you might find walk_tb useful....and a bit painful.
import traceback
try:
library_function(my_callback, 'foo')
except:
tb_gen = traceback.walk_tb(sys.exc_info()[2])
There is....entirely too much to discuss here. .walk_tb takes a traceback object, you may remember from the previous method that the 2nd index of the returned tuple from sys.exec_info is just that. It then returns a generator of tuples of frame object and int (Iterator[Tuple[FrameType, int]]).
These frame objects have all kinds of intricate information. Though, whether or not you'll actually find exactly what you're looking for, is another story. They may be complex, but they aren't exhaustive unless you play around with a lot of frame inspection. Regardless, this is what the frame objects represent.
What you do with the frames is upto you. They can be passed to many functions. You can pass the entire generator to StackSummary.extract to get framesummary objects, you can iterate through each frame to have a look at [0].f_locals (The [0] on Tuple[FrameType, int] returns the actual frame object) and so on.
for tb in tb_gen:
print(tb[0].f_locals)
That will give you a dict of the locals for each frame. Within the first tb from tb_gen, you'll see MyException as part of the locals....among a load of other stuff.
I have a creeping feeling I have overlooked some methods, most probably with inspect. But I hope the above methods will be good enough so that no one has to go through the jumble that is inspect :P
Chase's answer above is phenomenal. For completeness's sake, here's how I implemented their second approach in this situation. First, I made a function that can search the stack for the specified error type. Even though the chaining in my example is implicit, this should be able to follow implicit and/or explicit chaining:
import sys
import traceback
def find_exception_in_trace(exc_type):
"""Return latest exception of exc_type, or None if not present"""
tb = traceback.TracebackException(*sys.exc_info())
prev_exc = tb.__context__ or tb.__cause__
while prev_exc:
if prev_exc.exc_type == exc_type:
return prev_exc
prev_exc = prev_exc.__context__ or prev_exc.__cause__
return None
With that, it's as simple as:
while True:
something = input('Enter something: ')
try:
library_function(my_callback, something)
except LibraryException as exc:
if (my_exc := find_exception_in_trace(MyException)):
print(my_exc)
continue
raise exc
That way I can access my inner exception (and print it for now, although eventually I may do other things with it) and continue. But if my exception wasn't in there, I simply reraise whatever the library raised. Perfect!
Lets assume there is a method, and I want this method to be called only at certain conditions of a class variable, and otherwise I want to throw an exception:
def foo(self):
if not self.somecondition:
raise ????
else:
#do the thing it supposed to do
Now I am looking for a correct exception for that. I went through them all at python built-in Exceptions docs and found nothing suitable. The classic valueerror is not quite suitable because there is not necessarily a problem with the values but rather with the method being called in this
circumstances.
What exception should I use then? Do I need to create my own in this case or does python has a built in answer?
Background: I'm somewhat new to Python, and I'm writing a small roguelike with TDL while taking a course on Python. I'm attempting to make things "pythonic" (my background is mostly in C#).
According to my courseware, there are three things that are "pythonic":
Throw standard exception types unless you really need something different
Don't check pre-conditions extensively; use try/except and recover appropriately
Use duck-typing. Don't check if methods exist, just call them.
In the main loop of my game, I have a collection of entities. I iterate over them and, if they're walkable, call walk. My code looks something like this:
for e in self.area_map.entities:
try:
e.walk()
except AttributeError:
# not walkable
pass
except ValueError:
# all adjacent tiles are not walkable
pass
I recently introduced a bug where one of my entities referenced a variable that ended up being None instead of having a value. Instead of catching this error, I ended up with my entities simply not walking.
It turns out that my two exceptions that I catch can include a wide variety of different exceptions; however, I don't want to hide them -- I only want to hide specific cases (one where the method doesn't exist, and one where my code throws a ValueError).
What's the right way of doing this?
Currently, I'm checking if the exception message is something specific, which smells to me (what if a newer version of Python tweaks the exception message slightly?)
My code now looks like this:
for entity in self.area_map.entities:
try:
entity.walk()
except AttributeError as a:
# AttributeError => entity isn't walkable.
message = str(a)
if not "object has no attribute 'walk'" in message:
raise
except ValueError as v:
# ValueError => nothing adjacent to walk to.
message = str(v)
if message is not "There are no available adjacent locations":
raise
What's the right way to do this?
What does "Error return without exception set" commonly mean? I am trying to call a Python method that should return a list.
for facet in dispPart.FacetedBodies:
#Tag
facet_tag2=thisFctBody.Tag
#calling this method returns an "error return without exception set"
face_list=facet.GetFaces()
This is what I've found on it so far
You shoud tell what third party Python module you are using - this error message implies there is something wrong in that code, not yours. (ok, from your link, it is "NXOpen Python API")
Specifically, the third party module, interfacing with the Python C API returned an incorrect result, reporting an exception should have been raised, but did not tell Python which exception is that.
It is possible that there is something incorrect in your input data that, if fixed, could allow for normal return of the desired call - nonetheless it is buggy as it is.
One thing you might try is to call some other method on your facet object to check if, for example, it is not empty.