RFC,ENH: On C++ exceptions

[HaoZeke]

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.

Some references for the implementation:

[1] https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-errors
[2] https://learn.microsoft.com/en-us/cpp/cpp/errors-and-exception-handling-modern-cpp?view=msvc-170
[3] https://learn.microsoft.com/en-us/cpp/cpp/how-to-interface-between-exceptional-and-non-exceptional-code?view=msvc-170
[4] https://isocpp.org/wiki/faq/exceptions

[jajhall]

An interesting thought. I've grown up with the idea that throwing exceptions was always to be avoided. However, I've noted you view on the convenience within Python. However, as we've now seen in relation to #1367 , there are sure to be many users who will object to such "fatal" terminations of HiGHS.

[HaoZeke]

I'm not sure the discussion in #1367 is pertinent to exception handling however, I understand that calling exit explicitly is a bad idea in the library, but in this case it is more about catching the already propagating exception (std::length_error in this case) and simply recasting to something with more information (from a HiGHs user perspective). Indeed, in this instance at least, handling the exception prevents an ongoing fatal termination event, and so should be in keeping with the discussion on exit in #1367.

[HaoZeke]

For example, the error in the original SciPy issue is still throwing an exception (and will always do so), its just not anything which is very meaningful.

It would be nicer to upstream the exception logic here, since then we could add integer equivalents for the C bindings (catch the exception before handing off to the C interface and translate it to an error code).

[HaoZeke]

I would however, concur given #1367 that raising new exceptions in the HiGHs codebase is undesirable and unlikely to be acceptable, though catching and rethrowing standard exceptions could still be amenable?

[jajhall]

Catching exceptions such as memory allocation cleanly is worthwhile. By all means suggest a way to do it. I don't have the time...

[HaoZeke]

Sure, I'll put up a PR.

[mckib2]

In general, -1 from me for exceptions. Requiring exception handling to be enabled removes HiGHS from consideration in most safety critical code bases (if you care about that) and common C++ coding standards. If you're not wanting to appeal to the safety critical crowd and binary size isn't a huge issue, then exceptions may be desirable for the reasons mentioned above.

[HaoZeke]

My 2 cents on this right now is that as long as the C API needs to be supported, there isn't much of a benefit using exceptions since we'd still need an error structure for the C API, so it might as well be used on the C++ side as well (to be fair I think exceptions are ever so slightly faster in pure C++ though).

[jajhall]

What do you mean by "so long as the C API needs to be supported"? Are you suggesting that it might become redundant?

[HaoZeke]

No, that wouldn't be a good idea ever, C is the most inter-operable language (e.g. Fortran-C). However, I did mean that the benefits of exception handling in C++ (localization of the error, easy to catch and rethrow etc.) largely disappear if the error code needs to be propagated to C. So for example, we might allow throwing various kinds of specialized errors for more meaningful end-user interpretation in C++ and Python, but we'd still need to either:

• Convert them to a catch-all error before passing to C (e.g. logic_error input_error etc all just become one error code (say, 52) corresponding to the C API raising "User Error)
• Map each C++ / Python exception to a C error code (at which point using exceptions becomes all but pointless)