[Bug]: Exceptions raised when `PyErr_SetHandledException` is set don't set the context correctly
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.6k
- Forks
- 155
- Avg merge
- 9h 42m
- Merged PRs (30d)
- 36
Description
Describe the bug
In Python, raising an exception in an except block leads to the __context__ attribute on the new exception being set. This works correctly in GraalPython.
However the C API equivalent doesn't end up setting __context__. C API raised exceptions appear to have __context__ set correctly when raised from a Python catch block. However, neither Python nor C API execptions have __context__ set correctly when the handled exception is set with PyErr_SetHandledException.
Below is an example. I've used Cython for a quick way of wrapping it, but I think all the interesting behaviour is in the manual C API code.
// nocontexth.h
int raise_value_error(void) {
PyErr_SetString(PyExc_ValueError, "I'm a value error");
return -1;
}
int raise_type_error(void) {
PyErr_SetString(PyExc_TypeError, "I'm a type error");
return -1;
}
int raise_and_handle_exceptions(void) {
PyErr_SetString(PyExc_ValueError, "I'm a value error");
PyObject *exc = PyErr_GetRaisedException();
PyErr_SetHandledException(exc);
PyErr_SetString(PyExc_TypeError, "I'm a type error");
PyErr_SetHandledException(NULL);
return -1;
}
int raise_then_call_python(PyObject *callable) {
PyErr_SetString(PyExc_ValueError, "I'm a value error");
PyObject *exc = PyErr_GetRaisedException();
PyErr_SetHandledException(exc);
PyObject_CallNoArgs(callable);
PyErr_SetHandledException(NULL);
return PyErr_Occurred() ? -1 : 0;
}
# nocontext.pyx
cdef extern from "nocontexth.h":
cpdef int raise_value_error() except -1
cpdef int raise_type_error() except -1
cpdef int raise_and_handle_exceptions() except -1
cpdef int raise_then_call_python(object) except -1
Compile this with cythonize -if nocontext.pyx.
# testnocontext.py
import nocontext
import traceback
def run_python():
try:
raise ValueError("I'm a value error")
except Exception:
raise TypeError("I'm a type error")
def run_both_compiled():
nocontext.raise_and_handle_exceptions()
def raise_first_compiled():
try:
nocontext.raise_value_error()
except Exception:
raise TypeError("I'm a type error")
def raise_second_compiled():
try:
raise ValueError("I'm a value error")
except Exception:
nocontext.raise_type_error()
def raise_then_call_python():
def f():
raise TypeError("I'm a type error")
nocontext.raise_then_call_python(f)
for name in ["run_python", "run_both_compiled", "raise_first_compiled", "raise_second_compiled", "raise_then_call_python"]:
print(name)
print("-"*len(name))
try:
globals()[name]()
except:
traceback.print_exc()
print("\n\n")
Run this with python testnocontext.py.
Three of the tests work correctly. The two that don't are run_both_compiled and raise_then_call_python which suggests to me that the problem is with setting the handled exception from C.
Operating system
Linux
CPU architecture
x86_64
GraalPy version
25.0.2 and 25.0.3
JDK version
No response
Context configuration
No response
Steps to reproduce
Full example is in the "describe the bug" section
Expected behavior
__context__ set correctly
Stack trace
Additional context
This isn't causing me a real issue - it's just something I spotted from when adding some Cython tests. I've fixed it by disabling the tests in GraalPython. The effect of not fixing it is slightly worse exception messages but nothing more major.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by running the provided Cython example on GraalPy 25.0.2 or 25.0.3 and compare the context values for the five functions. Trace the C API paths involving PyErr_SetHandledException, PyErr_GetRaisedException, and PyErr_SetString. Done means C-raised exceptions receive the expected context in run_both_compiled and raise_then_call_python without regressing the three working cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, python
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100