viferga
commented
2 years ago I have implemented support for exceptions, for now I am going to detail the tasks that are done and the ToDo list:
Tasks Done:
- Implement base structure for handling exceptions at language level (not yet implemented at MetaCall level but I have left a base for that: https://github.com/metacall/core/blob/31a2c99bf569f786d0b903af7e2aa6e3ff7dbabd/source/metacall/source/metacall_error.c )
- Implemented exceptions in NodeJS port and loader.
- Implemented exceptions in Python loader (only in function invoke, not in class static methods or object methods).
TODO:
- Implement (once NodeJS class and object are supported) support for exceptions in class static methods and object methods.
- Implement support for exceptions in python static class methods and object methods.
- Implement support for exceptions in python port.
- Implement support at API level (MetaCall C API) for exceptions (or errors), this is unrelated of exceptions as values between languages although we can try to unify both. But usually C APIs try to be simple in that sense.
- Implement support for complex data types and derived exceptions: https://github.com/metacall/core/blob/31a2c99bf569f786d0b903af7e2aa6e3ff7dbabd/source/reflect/source/reflect_exception.c#L38
We should review if we should deal with exceptions on ports related to other methods like await or load. I am not sure about this because the current implementation method what does is transform any throw or raise into a value and return it. There's a new MetaCall type called throwable which represents that some runtime raised some value (the value can be an exception or any other value). This may be a task related to the C API exception handling rather than the reflect value exceptions.
A part from this, we should implement the same for the rest of languages, which can be an overwhelming task but we can do it step by step.
I have added here the diff of all commits (it includes other extra commits of non related things, but at least it can give an idea of how this has been done and how to add new languages): https://github.com/metacall/core/compare/6171a83f8b5928a93fc6a0a08e1be3508ecbde53...31a2c99bf569f786d0b903af7e2aa6e3ff7dbabd
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:
.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.