Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Bug]: Exceptions raised when `PyErr_SetHandledException` is set don't set the context correctly

Abierto
  • ¿Algo no está bien?
#980 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
c, python
Área
api, backend

Línea de trabajo

Empieza ejecutando el ejemplo de Cython proporcionado en GraalPy 25.0.2 o 25.0.3 y compara los valores de context para las cinco funciones. Sigue las rutas de la C API que implican PyErr_SetHandledException, PyErr_GetRaisedException y PyErr_SetString. Se considera terminado cuando las excepciones generadas por C reciben el context esperado en run_both_compiled y raise_then_call_python sin hacer que regresen los problemas en los tres casos que funcionan.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug
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.

Lenguaje dominante
Python
Estrellas
1.6k
Forks
155
Merge medio
7 h 35 min
PR fusionados (30 d)
48

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de oracle/graalpython

Todos los issues de oracle/graalpython

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.