Skip to content
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

Handle errors without terminating the whole program #328

Open
5E-324 opened this issue Apr 23, 2023 · 2 comments
Open

Handle errors without terminating the whole program #328

5E-324 opened this issue Apr 23, 2023 · 2 comments

Comments

@5E-324
Copy link
Contributor

5E-324 commented Apr 23, 2023

Currently, errors are handled by ctx->error_func, which is set by MIR_set_error_func. According to the way it's used (e.g. in MIR_link), it seems that the callers expect it to terminate the program, because otherwise they will continue as if there's no error. But sometimes, the program needs to record the error and continue.

In order to achieve that:

  • The error handler need a place to store the errors:
    • An optional pointer to a custom data structure is set when calling MIR_set_error_func.
    • When calling error_func, this pointer is passed as an parameter.
  • The caller should not rely on error_func for termination. When an error is occurred, it should:
    • Either terminate immediately, or (more preferably) continue and report more errors until error count limit is reached, like many compilers.
    • Do not save results.
    • Indicate failure in its return value.

Alternatively, the errors can be saved in the context. If a function fails, the program can retrieve them by calling a function like GetLastError or glGetError and glGetShaderInfoLog

Error handling of OpenGL can be used as a reference since both OpenGL and MIR involve compilation and linking. See 1 2 3. Both of the aforementioned methods exist in OpenGL.

The method used in c2mir_compile is also usable.

Error handling methods which MIR uses also need to be unified. Currently, the three related functions c2mir_compile, MIR_scan_string, and MIR_link handle and report errors in three different ways!

@5E-324 5E-324 changed the title Handle errors without terminate the whole program Handle errors without terminating the whole program Apr 24, 2023
@vnmakarov
Copy link
Owner

Thank you for your feedback. It is important to me.

I am agree the error handling could be improved. I did not pay much attention to this as I believe the development of MIR code is different from other programming languages with a typical cycle of getting errors and fixing them manually. I expect that the MIR code is generated and fixing one error requires more time than in the mentioned cycle.

Still I'll try to find time to work on this issue. Unfortunately I do not know when it happens as I have more high-priority projects these days. Also I am open to pull requests to improve the error handling.

@5E-324
Copy link
Contributor Author

5E-324 commented Apr 27, 2023

Surely, MIR code is generated. However, sometimes it is generated from user provided C code, the errors in which need to be reported to the user. Syntax errors are handled by c2mir, so no problem. But linking errors are discovered by MIR_link, in this case, it needs to handle the errors in a different way.
I can try to improve this. How would you like MIR to handle linking errors? Personally, I prefer using a method similar to what OpenGL uses: MIR_link will return false in case of failure, the error messages will be saved in ctx, and can be retrieved by a calling a function. Do you think this is OK?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants