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

Better parsing exceptions #299

Merged
merged 12 commits into from
Jul 11, 2024
Merged

Better parsing exceptions #299

merged 12 commits into from
Jul 11, 2024

Conversation

nevrome
Copy link
Member

@nevrome nevrome commented May 24, 2024

There are some trident error messages that are not well rendered on the command line. This PR is an attempt to improve them. Here's some examples of what I did so far:


-f "<<>" (or other broken CLI input that goes through parsec)

option -f: PoseidonPoseidonEntityParsingException "(line 1, column 2):\nunexpected \"<\""

Now:

option -f: Error when parsing the forge selection (either -f or --forgeFile):
unexpected "<"

And with --forgeFile, where the file contains only <<>

[Error]   Error when parsing the forge selection (either -f or --forgeFile):
unexpected "<"

YAML file with broken orcid field (or other yml fields)

[Warning] Could not parse YAML file 2010_RasmussenNature/POSEIDON.yml: AesonException "Error in $.contributor[0].orcid: (line 1, column 5):\nunexpected \".\""
[Warning] Could not parse YAML file 2010_RasmussenNature/POSEIDON.yml:
Aeson exception:
Error in $.contributor[0].orcid:
unexpected "."

With a broken date in lastModified:

[Warning] Could not parse YAML file /home/schmid/agora/community-archive/2010_RasmussenNature/POSEIDON.yml: AesonException "Error in $.lastModified: could not parse date: Failed reading: date must be of form [+,-]YYYY-MM-DD"
[Warning] Could not parse YAML file 2010_RasmussenNature/POSEIDON.yml:
Aeson exception:
Error in $.lastModified: could not parse date: Failed reading: date must be of form [+,-]YYYY-MM-DD

@nevrome nevrome marked this pull request as draft May 24, 2024 13:23
Copy link

codecov bot commented May 24, 2024

Codecov Report

Attention: Patch coverage is 27.77778% with 26 lines in your changes missing coverage. Please review.

Please upload report for BASE (master@e8ff841). Learn more about missing BASE report.

Files Patch % Lines
src/Poseidon/Utils.hs 20.83% 14 Missing and 5 partials ⚠️
src/Poseidon/EntityTypes.hs 25.00% 1 Missing and 2 partials ⚠️
src/Poseidon/BibFile.hs 0.00% 1 Missing ⚠️
src/Poseidon/CLI/Forge.hs 50.00% 1 Missing ⚠️
src/Poseidon/CLI/Genoconvert.hs 50.00% 1 Missing ⚠️
src/Poseidon/Package.hs 50.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff            @@
##             master     #299   +/-   ##
=========================================
  Coverage          ?   68.37%           
=========================================
  Files             ?       26           
  Lines             ?     3554           
  Branches          ?      403           
=========================================
  Hits              ?     2430           
  Misses            ?      721           
  Partials          ?      403           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@nevrome
Copy link
Member Author

nevrome commented May 24, 2024

I decided to use the opportunity to also suggest a solution for #244. I think the error shortening mechanism is only really relevant for the excessive PoseidonGenotypeExceptionForward. So I made it a feature of only this exception to include an ErrorLength to which its text should be truncated. This abolishes the general error truncation and makes it a much more specific feature.

Most importantly it now also covers warnings:

image

@stschiff
Copy link
Member

Very nice, looking forward to it.

@nevrome
Copy link
Member Author

nevrome commented Jun 28, 2024

I lost track of this PR. But it looks like the changes I applied so far are meaningful and complete. Maybe you could have a look, @stschiff. It's time for a Poseidon release with the amazing --ordered flag!

@nevrome nevrome marked this pull request as ready for review June 28, 2024 12:04
@nevrome nevrome requested a review from stschiff June 28, 2024 12:04
@stschiff
Copy link
Member

stschiff commented Jul 2, 2024

Yes, true, will try to get this finished before I go on vacation, similarly to #304.

Copy link
Member

@stschiff stschiff left a comment

Choose a reason for hiding this comment

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

Ok, looks great. Love the showParsecErr trick.

My own preference is not to make definitions like data ErrorLength = CharInf | CharCount Int deriving Show but instead use Maybe Int for this, but we had this discussion before, and I guess it comes down to personal coding style. My argument is that something like CharInf, while seemingly adding semantic interpretability, forces me to not only look up the function definitions where this is used, but also the datatype definition. With Nothing on the other hand, I can just look up the function definition to understand its semantics. Anyway, totally fine like you have it now.

I have not tested this PR at all, and don't have time before vacation for this, so if you've tested things, then I certainly approve merging this in.

@nevrome nevrome merged commit 92d0ca3 into master Jul 11, 2024
2 checks passed
@nevrome nevrome deleted the betterParsecErrors branch July 11, 2024 14:25
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.

2 participants