GLPK/Error handling

This page describes strategies for dealing with faults states in GLPK &mdash; while noting that prevention is usually better than cure.

GLPK error hook function
If a run-time error occurs in the GLPK library, GLPK, by default, normally releases the GLPK library environment and aborts the calling program. If you would like to prevent the calling program being aborted, then define a custom error hook function and register this function by calling glp_error_hook. Your hook function should first invoke glp_free_env to free the GLPK library environment and then apply the longjmp call from the C standard library header setjmp.h to return control to the calling program. The calling program can then take the appropriate action, which may include an orderly retreat and exit.

The example below illustrates the use of a custom error hook function (note also the Doxygen markup in some comment blocks):

Catching and handling user interrupts
Users sometimes wish to terminate a running command-line program. This is normally achieved by hitting Ctrl-C which causes the operating system to send a SIGINT signal to the active program.

If the SIGINT is not caught and handled by the program, the system terminates the process more-or-less instantly. Programmers often like to offer a more graceful approach. GLPK provides the glp_error_hook hook function for this purpose. If you wish to terminate the solver midway through a solution, simply call the following from within this hook:

If an MIP problem is running and you would like to let the current solution complete, then use:

The code for registering the hook function is not given here but further details can be found in this 2011 posting.

In GLPK for Java an error inside the GLPK library results in an exception of class org.gnu.glpk.GlpkException. Methods GLPK.glp_java_error and GLPK.glp_ios_terminate are provided. These can be called in terminal or callback listeners.