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

filename_parser() no longer raises an exception for unrecognized files #1614

Merged

Conversation

bhilbert4
Copy link
Collaborator

Adjust the filename_parser() such that when it is called on a filename it doesn't recognize, it no longer raises an exception, but instead returns a dictionary with a key indicating that the filename wasn't recognized.

@bhilbert4 bhilbert4 self-assigned this Jul 10, 2024
@pep8speaks
Copy link

pep8speaks commented Jul 10, 2024

Hello @bhilbert4, Thank you for updating !

Cheers ! There are no PEP8 issues in this Pull Request. 🍻

Comment last updated at 2024-08-20 18:17:34 UTC

@bhilbert4 bhilbert4 changed the title WIP: filename_parser() no longer raises an exception for unrecognized files filename_parser() no longer raises an exception for unrecognized files Aug 16, 2024
@bhilbert4
Copy link
Collaborator Author

@mfixstsci @york-stsci I've cleaned up the changes here to make them a little more consistent amongst the various calls to filename_parser(). Tests are all passing, so I think this is ready for review. I'll take care of the PEP8 stuff momentarily.

Copy link
Collaborator

@york-stsci york-stsci left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a lot of redundant comments, but my basic point is that we should probably choose a specific way of getting output from the file parser, testing that output for validity, and reacting to it. I don't mind if we're doing try/except or if/then, but we should probably pick one and use it.

My second note is that we need to make sure that, when the parser fails, we log that failure in a way that's connected not only to the specific monitor that's running, but to the specific place within that monitor where the failure happened.

The combination of the above suggests to me that, annoying as it is, wrapping the call to filename_parser() in a try/except block, and logging the exception (along with what stage of the monitor it is, what file it was trying to parse, and how it got that file (i.e. from user input for a search, from a self-generated list, from some other source) is probably the cleanest way to make sure we have the necessary context.

jwql/jwql_monitors/generate_preview_images.py Show resolved Hide resolved
jwql/jwql_monitors/generate_preview_images.py Show resolved Hide resolved
jwql/jwql_monitors/generate_preview_images.py Show resolved Hide resolved
jwql/jwql_monitors/generate_preview_images.py Show resolved Hide resolved
jwql/jwql_monitors/generate_preview_images.py Show resolved Hide resolved
jwql/jwql_monitors/monitor_filesystem.py Show resolved Hide resolved
jwql/utils/utils.py Show resolved Hide resolved
@bhilbert4
Copy link
Collaborator Author

Ok @york-stsci, have a look. I updated the files to add logging statements in the calling functions. I kept the logging statement in filename_parser() itself. Maybe with testing we can see if that statement makes it into the expected log. Running locally, I can try a few of these cases tomorrow.

Copy link
Collaborator

@mfixstsci mfixstsci left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @bhilbert4 assuming that you've addressed all of @york-stsci comments I am cool with merging this in.

@bhilbert4 bhilbert4 merged commit 5fb8cd2 into spacetelescope:develop Aug 20, 2024
11 checks passed
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 this pull request may close these issues.

4 participants