Skip to content

Conversation

@tdsmith
Copy link

@tdsmith tdsmith commented May 15, 2025

Sometimes you have an unsolveable optimization problem running in a subprocess. It's useful to allow NoSolutionError to be pickleable so that the exception can propagate back to the main process.

Without this change, unpickling the exception fails. BaseException has an implementation of __reduce__, which defines the state to pickle, which remembers the args that its constructor received. Upon deserialization, the constructor of the exception is called with the arguments that the BaseException constructor received.

If the BaseException constructor does not receive NoSolutionError's mandatory problem argument, we will try to call the NoSolutionError constructor without it, which will fail.

An alternative is reimplementing __reduce__ on NoSolutionError.

Sometimes you have an unsolveable optimization problem running in a
subprocess. It's useful to allow NoSolutionError to be pickleable so
that the exception can propagate back to the main process.

Without this change, unpickling the exception fails. BaseException has
an implementation of __reduce__, which defines the state to pickle,
which remembers the args that its constructor received. Upon
deserialization, the constructor of the exception is called with the
arguments that the BaseException constructor received.

If the BaseException constructor does not receive NoSolutionError's
mandatory `problem` argument, we will try to call the NoSolutionError
constructor without it, which will fail.

An alternative is reimplementing __reduce__ on NoSolutionError.
@Zulko
Copy link
Member

Zulko commented Oct 20, 2025

This sounds reasonable to me 👍 @veghp what do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants