-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error handling in READ_ALL_COMMANDS
#4199
Comments
I think the idea was/is to set the ERROR_OUTPUT global in GAP to an output stream to which the error messages then are written. (That's not necessarily a great API, but it was the easiest to pull of on short notice back then.) This is of course what |
The right way to do this is to check the return value of `evalstr_ex`, and to call `GAP.error_handler` if necessary, as was proposed in the discussion of gap-system/gap/issues/4199. This is intended to resolve issue oscar-system#580. (The change does of course not affect the problems described in issue oscar-system#596.)
Yes, calling |
The right way to do this is to check the return value of `evalstr_ex`, and to call `GAP.error_handler` if necessary, as was proposed in the discussion of gap-system/gap/issues/4199. This is intended to resolve issue #580. (The change does of course not affect the problems described in issue #596.)
LibGAP's
GAP_EvalString
calls the kernel functionREAD_ALL_COMMANDS
, which does the same as the GAP functionREAD_ALL_COMMANDS
.Consider the following GAP session.
The syntax error message is printed to the screen, a result is returned, and the
false
entry in the result indicates that an error happened.When one uses the above input via LibGAP, what is the recommended way to handle the error in the code that calls
GAP_EvalString
, that is, access the error message (in order to report it) and then empty the buffer?This error handling is currently missing in the GAP-Julia integration, see oscar-system/GAP.jl/issues/580.
The text was updated successfully, but these errors were encountered: