NCAR
Implementation of a logger/error handler
The existing error logging/handling method via the two mandatory CCPP arguments errmsg/ccpp_error_message and errflg/ccpp_error_flag should be replaced with a proper logger/error handler.
Ideally it would provide a call stack to where an error was generated and what the error is, and different logging levels (debug, info, warning, error, critical?).
Another nice-to-have would be to be able to redirect these log messages to separate log files or stdout/stderr or some other method that can be informed by the host model.
This is a post-capgen-unification task.
Another nice-to-have would be to be able to redirect these log messages to separate log files or stdout/stderr or some other method that can be informed by the host model.
I thought the framework was not supposed to do any I/O. Am I missing something?
Another nice-to-have would be to be able to redirect these log messages to separate log files or stdout/stderr or some other method that can be informed by the host model.
I thought the framework was not supposed to do any I/O. Am I missing something?
We definitely said that schemes are not allowed to do I/O, I don't recall if we also included the framework itself. But if we make it a requirement that the I/O options are configured entirely in the host model, say the host model decides to write the CCPP log messages to some other output stream or the same stream that it uses for other components, then that is totally fine in my opinion.
If output is configured, does the framework still return the error object to the host model? How does the host model know what messages have been output? This feels a lot more complicated to get right, please spell out the details of how these systems should interact.
If output is configured, does the framework still return the error object to the host model? How does the host model know what messages have been output? This feels a lot more complicated to get right, please spell out the details of how these systems should interact.
Let us take some time to flesh out the requirements in one of our meetings and write them down, then see what options we have to implement those and where we have to make compromises. It will depend a lot on the error handler's capabilities on what we are able to do and how to implement it exactly.