Error handling PoC#1
Conversation
| // Error Handling Abstraction | ||
|
|
||
| /// Zero-sized type indicating that a Python exception has been set. | ||
| /// Using this type will ensure `Result<&PyObject, ExecutedErr>` and `Result<PyRc, ExecutedErr>` | ||
| /// to be same size as `*mut PyObject`. | ||
| #[derive(Debug, Clone, Copy)] | ||
| pub struct ExecutedErr; | ||
|
|
||
| /// Enum representing different ways to set a Python exception. | ||
| /// | ||
| /// This type is NOT stored in Result - it's immediately converted to | ||
| /// `ExecutedErr` via `.into()`, which triggers the actual C API call. | ||
| pub enum MakeErr { | ||
| SetString(*mut PyObject, *const c_char), | ||
| SetObject(*mut PyObject, *mut PyObject), | ||
| SetNone(*mut PyObject), | ||
| NoMemory, | ||
| } | ||
|
|
||
| impl MakeErr { | ||
| fn execute(self) -> ExecutedErr { | ||
| match self { | ||
| MakeErr::SetString(exc_type, msg) => { | ||
| unsafe { PyErr_SetString(exc_type, msg) }; | ||
| } | ||
| MakeErr::SetObject(exc_type, value) => { | ||
| unsafe { PyErr_SetObject(exc_type, value) }; | ||
| } | ||
| MakeErr::SetNone(exc_type) => { | ||
| unsafe { PyErr_SetNone(exc_type) }; | ||
| } | ||
| MakeErr::NoMemory => { | ||
| unsafe { PyErr_NoMemory() }; | ||
| } | ||
| } | ||
| ExecutedErr | ||
| } | ||
|
|
||
| #[inline] | ||
| pub fn type_error(msg: &CStr) -> Self { | ||
| Self::SetString(unsafe { PyExc_TypeError }, msg.as_ptr()) | ||
| } | ||
| } | ||
|
|
||
| impl From<MakeErr> for ExecutedErr { | ||
| #[inline] | ||
| fn from(exc: MakeErr) -> Self { | ||
| exc.execute() | ||
| } | ||
| } | ||
|
|
||
| pub type PyResult<T> = Result<T, ExecutedErr>; |
There was a problem hiding this comment.
I think we should discuss how we want to handle this in the future (as well as for the RC PoC PR). We should probably move it into a separate module so it can be reused by other (future) modules. What do you think?
There was a problem hiding this comment.
Totally agree we should discuss the design of these abstractions. We should probably move these to a new cpython-safe or some such module as you suggest. I also wonder if we should design the PyObject/other object abstractions first, since pretty much everything will build off of that?
There was a problem hiding this comment.
I will move this code to the new crate once it is created. I am just avoiding to naming or placing the new crate.
I also wonder if we should design the PyObject/other object abstractions first,
In general, We have to write more code and discuss about the new requirements to make better abstractions.
The more code we write, the more idea about better abstraction will pop.
Even if we don't have a good abstraction what we need, we have to write them with C-APIs to get idea how to design to make them better.
If you are strictly talking about PyObject and lifetime types, it probably will be. Because they are well researched by PyO3 team for years. (Actually we'd better to study PyO3 a lot to learn what was successful or not)
Otherwise discussing about multiple topics at the same time will gives better idea than giving them priority first or second.
…er() (python#140574) * pythongh-140281: Doc: Update free-threading how-to * pythongh-140281: Doc: Update free-threading how-to * Fix trailing whitespace * doc fixing of the cpython fixes#84116 * Docs: Document help and aliases for argparse.add_parser() (pythongh-84116) * Docs: Document help and aliases for argparse.add_parser() (pythongh-84116) * Fix trailing whitespace * Fix trailing whitespace * Fix trailing whitespace * Fix trailing whitespace * Fix trailing whitespace * Fix trailing whitespace * Fix trailing errors * Fix trailing errors and spaces * Fix docutils formatting, NEWS ref, and trailing whitespace * Docs: Update argparse.rst and add NEWS entry * Delete Doc/howto/free-threading-python.rst * Delete Misc/NEWS.d/next/Documentation/2025-10-25-00-49-43.gh-issue-140281.tuMQUe.rst * adding the depreceated tag * The error indexing was fixed * Fix trailing whitespace * Restore missing free-threading documentation * fixing some minor error * fixing some minor error part 2 * fixing some minor error part 3 * Fix NEWS entry format * Final cleanup of NEWS entry format 2 * changes in the argparse.rst * Remove unnecessary NEWS entry * Fixing the issue as requested * Added the Changes done before. * done the changes * done the changes#1 * Apply suggestion from @picnixz Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> * Apply suggestion from @picnixz Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> * Done the changes * Done the new changes * The versionadded is rectified * Update Doc/library/argparse.rst Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> * Docs editing * Docs fixing whitespace * Docs rectifiying * little bit rectification * Indentation rectification * Indentation rectification 1 * Apply suggestion from @picnixz Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> * deprecated rectification * Remove mistakenly added NEWS entry * Update Doc/library/argparse.rst Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> * changes Rust-for-CPython#1 Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> * Update Doc/library/argparse.rst 2 Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> * removed useless thing Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> * changed according to the request Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> * Updated the test part --------- Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
3 participants
No description provided.