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
code generation for errors #2871
Comments
Personally, I prefer option 1. The error codes should change only very infrequently, which makes the additional effort of manually writing the C code and keeping other languages in sync negligible. The initial effort should also be less compared to setting up any form of automatic generation. Why not option 2? Mustache templates have to be supplied with the input data somehow. Either we have to use a custom executable that is compiled at build time. In that case we would just get rid of the Also Why not option 3? Generating the C code might work in CMake, but more complex languages might have problems with using CMake. If we do decide to use some form of code-generation, we should only generate the parts that absolutely need to be generated. For example the current |
I also prefer option 1 because of stable error codes. Adding code generation also adds unnecessary complexity to the overall code which is again error prone. |
@kodebach thank you for your elaboration on option 2 I think it is quite clear that we go for option 1, @Piankero can you please write up the decision? For the bindings it means that not much changes. What would be great if we had a binding writing tutorial, describing:
I hope we can extend this tutorial for the different situations we see in different languages. @Piankero can you please start to write the tutorial, in particular the error handling section (how to implement inheritance, ...) |
In the previous error concept it was very useful to generate macros as we often added new errors. The code generation itself, however, is quite complicated (C++ code that prints the code; which is also not ideal for cross compilation, see also #2814).
Now we have a more or less fixed set of a few errors. So the question is what we should do:
@PhilippGackstatter @raphi011 @kodebach @Piankero What do you think?
The text was updated successfully, but these errors were encountered: