Improve DPF Server error handling

[PProfizi]

Description of the feature

The current way DPF server errors are reported by PyDPF-Core is that the error message is put in a DPFServerException as-is.
This is an issue for several server errors which also share a form of server-side traceback or detailed failure information directly within the error message due to the C-layer.

This makes it very hard for front-ends to show user-friendly messages.

The objective is to find a way to separate the three information:

• a user-friendly readable error message
• the Python traceback
• the serve-side "traceback"

Steps for implementing the feature

Insert DPF Server error message parsing logic here to separate between actual message and traceback, with traceback put as note or equivalent additional information property:

pydpf-core/src/ansys/dpf/gate/errors.py

Line 8 in 16de04b

Exception.__init__(self, msg)

Warning: BaseException.add_note is only available starting with Python 3.11, meaning we have to find a workaround for 3.10 and less (maybe add a custom property to the Exception object, or create a custom Exception class to copy the add_note behavior.

Useful links and references

https://peps.python.org/pep-0678/
https://docs.python.org/3/tutorial/errors.html#enriching-exceptions-with-notes
https://docs.python.org/3.13/library/exceptions.html#BaseException.add_note

[PProfizi]

@BClappe

[BClappe]

Adding note may be a solution. I would also explore setting exception's context. I don't know if this may work or not, but this may be tried.
This solution would consider informing the user that an exception (may be simulated) in DPF server triggered an exception in PyDPF core, by listing tracebacks in one exception, instead of having the DPF stacktrace displayed as a string at the end of the python stacktrace (as proposed by Paul with add_note).

Here are some resources:

• https://docs.python.org/3.13/library/exceptions.html#exception-context
• https://docs.python.org/3/reference/datamodel.html#traceback-objects

[PProfizi]

Adding note may be a solution. I would also explore setting exception's context. I don't know if this may work or not, but this may be tried. This solution would consider informing the user that an exception (may be simulated) in DPF server triggered an exception in PyDPF core, by listing tracebacks in one exception, instead of having the DPF stacktrace displayed as a string at the end of the python stacktrace (as proposed by Paul with add_note).

Here are some resources:

• https://docs.python.org/3.13/library/exceptions.html#exception-context
• https://docs.python.org/3/reference/datamodel.html#traceback-objects

This is a good idea to investigate, but this would mean taking the server-side error message and somehow translating it into a pure-Python error with a Python traceback and context. I am not sure this is simple to do or will fit, and may even be confusing to users and developers. It would however be retro-compatible with Python 3.7 which is an advantage.
Let's see what we get from using add_note first and go from there.

Edit: The thing is Exception.__context__ must be an Exception, and Exception__traceback__ must be a TracebackType. This would mean creating a Python error for the server error and passing it as cause for the DPFServerException, but we are already wrapping the server error as a DPFServerException.