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

Add ability to filter certain error messages #85

Closed
ken-lauer opened this issue Jul 12, 2024 · 5 comments · Fixed by #95
Closed

Add ability to filter certain error messages #85

ken-lauer opened this issue Jul 12, 2024 · 5 comments · Fixed by #95

Comments

@ken-lauer
Copy link
Collaborator

Raising RuntimeError for certain errors is undesirable, depending on what the user is trying to do. This seems to be a recurring theme based on what I've heard and recently reported issues (#84)

If pytao could filter user-defined message classes such as these and redirect them to the logging system, maybe that would be a good solution? (cc @ChristopherMayes )

For example:

[ERROR | 2024-JUL-12 15:57:24] tao_set_invalid:
    UNSTABLE ORBIT AT EVALUATION POINT
    FOR DATUM: abc.x[4] with data_type: bpm_orbit.x

Not sure how it would look, but perhaps some simple string match like this could be fine:
tao.ignore_error("tao_set_invalid", "UNSTABLE ORBIT")

@ChristopherMayes
Copy link
Contributor

Yes, there are a few like this that aren't quite "errors" to me.

@DavidSagan what do you consider an "error" vs "warning"?

@DavidSagan
Copy link
Member

Essentially, an error occurs when "unexpectedly" the computation cannot be done. The problem is that where you draw the line is somewhat arbitrary.

@ken-lauer
Copy link
Collaborator Author

@DavidSagan I imagine it would be a massive effort to give all such errors a uniquely identifiable code (such as the above might be EVAL001 short for "unstable orbit at evaluation point")?

If we had some way of identifying the errors with unique codes, it'd be much easier for the user to opt out of certain messages or reclassify them as fatal/ignorable/etc.

@DavidSagan
Copy link
Member

About 1800 lines give or take. But something someone with only a little training could do. I think better would be to enable the User to opt out using the routine name generating the error which is already something that PyTao knows about.

@DavidSagan
Copy link
Member

Another thought is to add more error levels for finer control.

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

Successfully merging a pull request may close this issue.

3 participants