MetaCall currently has no mechanism to propagate errors to the caller, aside from a simple logging to notify the user. Exceptions are often part of the API, meaning that it is necessary to handle them in order to make use of these APIs properly. Therefore, being able to propagate exceptions through MetaCall is crucial for making it usable beyond trivial scenarios.

This issue tracks the error handling status in MetaCall core and is the place for discussions related to error handling. See also the GSoC 2021 ideas page.

You can find some of the error handling mechanisms of language runtimes here:

• Python: https://docs.python.org/3/c-api/exceptions.html#exception-handling
• NodeJS: https://nodejs.org/api/n-api.html#n_api_error_handling
• V8: https://v8.dev/docs/embed#exceptions
• Ruby: https://silverhammermba.github.io/emberb/c/#exceptions (See Ruby C API error handling #61)
• Java: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#exceptions

.Net Core seems to have no embedding API for exception handling and will probably keep being handled via a middle-man C# code. See the C# loader.

There are some ideas on how to go about implementing this, the straight-forward one is to introduce a new error type in the type system with generic error information like error message and so on, catch whatever exception is thrown from the calee and throw it on the other side of the language boundaries by constructing it again. This would of course mean specialized exceptions (subclasses) won't contain additional information. See the exception_type in reflect_exception.c.

Another approach might be to use the class type in the type system and have proper exceptions with class hierarchies but I can't comment on it much as I have pretty limited knowledge on how the class support works in MetaCall.

We probably also want to streamline the error handling in MetaCall core itself and make sure all the necessary functions have means to propagate their error status to the caller. Note that @viferga instists on not using exceptions or setjmp/longjmp in MetaCall itself with the argument that it would break languages with coroutines.