You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What would be the best way to add support for exceptions in the interface? Generate different bindings with a flag to generator?
Ideally, I would like to have meaningful messages inside exceptions. For example, include messages passed to isl_die. The main problem is that internal memory management relies on the errors being propagated until the user call through isl_stat/isl_bool or null pointers to do some cleenups. So we cannot just throw on isl_die. We could try to copy the message into the isl_ctx and then query it, similarly to errno in POSIX. This would complicate the wrapper functions and make them do the following:
find the ctx of their arguments;
do the call and check if it did not return error/null (except if marked as __isl_null);
if did return error, query the context and throw
stack unwinding should take care of clearing the relevant C++ wrappers.
This requires that all functions that may fail could obtain the context from their arguments. Is this the case?
Any other thoughts?
The text was updated successfully, but these errors were encountered:
What would be the best way to add support for exceptions in the interface? Generate different bindings with a flag to generator?
Ideally, I would like to have meaningful messages inside exceptions. For example, include messages passed to isl_die. The main problem is that internal memory management relies on the errors being propagated until the user call through isl_stat/isl_bool or null pointers to do some cleenups. So we cannot just throw on isl_die. We could try to copy the message into the
isl_ctx
and then query it, similarly toerrno
in POSIX. This would complicate the wrapper functions and make them do the following:ctx
of their arguments;__isl_null
);This requires that all functions that may fail could obtain the context from their arguments. Is this the case?
Any other thoughts?
The text was updated successfully, but these errors were encountered: