-
Notifications
You must be signed in to change notification settings - Fork 277
Description
I have been looking into the highs code and I was wondering if there have been any previous discussions on throwing exceptions in the code. As a concrete example consider the following code (in scipy) which crashes the interpreter (described in scipy/scipy#15888):
from scipy.optimize import linprog
import numpy as np
np.random.seed(0)
n_ctr = 500000
n_var = 500
c_ = np.ones(n_var)
A_ub = np.random.random((n_ctr, n_var))
b_ub = np.zeros((n_ctr, ))
res = linprog(c_, A_ub=A_ub, b_ub=b_ub, method='highs-ds', bounds=(0, None), options={'disp': True, 'presolve': True})
print('End')Which is rather elegantly fixed by throwing and re-throwing an appropriate exception (demonstrated in this PR to the SciPy HiGHs fork). Some things to keep in mind are that they are thread safe, and have generally zero overhead (unless an exception is actually thrown). They also simplify error handling within the code and for python bindings (which no longer need to check specialized error structures).
One caveat is that the C bindings cannot handle exceptions, and so they need to be caught and translated to an error status code. However, on whole exception handling makes the code more expressive and easier to debug / work with. It should also be noted that it does not need to (immediately or ever) replace the existing Result statuses and return values, which indicate more logical constraints and user-error. There's also extensive support for exceptions in Pybind11 so highspy will benefit as well.
If adding exceptions is acceptable, I'll make a PR similar to the SciPy fork here.