[REDMINE1D-345] [RM-8441] Refactor warning flag recording when an error occur Created: 25/Oct/23 Updated: 05/Dec/23 |
|
| Status: | Open |
| Project: | 1D Redmine |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Normal |
| Reporter: | Redmine-Jira Migtation | Assignee: | Redmine-Jira Migtation |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Created on 2023-10-24 14:32:26 by Didier Vibert. % Done: 0 in develop (and 0.44) when running a QSO linemeas only, with a linemeas catalog without the required columns (eg qso.VelocityAbsorption) the error "Context warning flag already exists" still appears ... <pre> </pre> The warning flags should not be recorded in the COperatorResultStore from the c++ exception (as it is the case now) but from the python process flow |
| Comments |
| Comment by Redmine-Jira Migtation [ 05/Dec/23 ] |
|
Comment by Didier Vibert on 2023-11-07 08:42:15: I propose to define a python context manager for dealing with stage/solver scopes, pushing a new scope at beginning, popping the scope and collect/store the warning flag in the resultStore at finalization. The use of the context manager (@with@ statement) could also be embedded in a decorator (as it is the case already for trapping exceptions). The advantage of using a context manager instead of explicitly storing the warning flag at the exception level, is that there will then be only one place (in the code) for storing each warning flag: at the ending of the corresponding context, whatever causes the end, ie exception or normal ending. |