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
Improve error UX? #1318
Comments
@dgollahon that specific crash is solved with
Subcommand, we could run whenever |
I recently had a neutral failure due to an
unparser
bug (mbj/unparser#311)mutant
spat out a ton of output that made it harder to see what actually went wrong. It seems like there are a lot more cases where i get amarshal data too short
exception with no other context than i remember as of a couple years back. Is there a way that could be handled more gracefully/recognized as not helpful information? For unparser failures in particular, it would be nice to just highlight that the code failed to round-trip. Maybe there could be an explicit check for that on a neutral failure and it could tell the user there was a parsing or unparsing bug?Example output:
The text was updated successfully, but these errors were encountered: