Properly expose SCIP error codes to users.

[rschwarz]

This applies to the rewrite (after #76 is merged).

Currently, the simple @SC macro is used everywhere, where on would use SCIP_CALL in C.
It only does an @assert to check that the return code is SCIP_OKAY.

It would be better to throw a custom exception, also explaining what happened.

Not sure if we can actually show the full stacktrace (including the SCIP calls). I believe this requires compiling SCIP in debug mode?

cc @fserra

[rschwarz]

See also MathOptInterface.jl/error.jl

[fserra]

the errors appear also in opt mode

[matbesancon]

Not sure if we can actually show the full stacktrace (including the SCIP calls). I believe this requires compiling SCIP in debug mode?

I'm not sure we will get a full stacktrace anyway if there is no error on the SCIP side, just a return code. We could just send a warning when the return code is not SCIP_OKAY, but I'm not sure there are many cases where a different retcode should not result in an error

[rschwarz]

I'm not sure what you mean with:

if there is no error on the SCIP side, just a return code

If I remember correctly, SCIP only uses return codes to do error handling, but the SCIP_CALL macro will also print a corresponding line for each layer of the stack. A return code different from SCIP_OKAY would then always signal an error.

I guess in the context of SCIP.jl, the most likely case would be an invalid stage. I don't think that these can be "dealt with" completely in the wrapper, so the user should at least get meaningful information for what happened and how to resolve the issue.

[matbesancon]

OK I see. So the goal would be to print the code before throwing an error instead of the assert in the macro?

[rschwarz]

For example, or even have SCIP print its internal stack trace. Not sure whether that would be helpful to the typical user of SCIP.jl, but it would definitely be convenient for users with SCIP experience.