8000 Improve error message usability · Issue #55 · pyasn1/pyasn1 · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Improve error message usability #55

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.

Sign up for GitHub

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

Jump to bottom
Open
ralienpp opened this issue Feb 6, 2024 · 2 comments
Open

Improve error message usability #55

ralienpp opened this issue Feb 6, 2024 · 2 comments

Comments

@ralienpp
Copy link
ralienpp commented Feb 6, 2024

My experience with pyasn1 is that it is great when it works out of the box, but when it doesn't - troubleshooting complex structures is a pain. I believe there are two key issues:

On top of that, there's also the complexity of ASN.1 itself - so when something doesn't work, I have doubts whether the root cause is in my misunderstanding of ASN.1, or in my misunderstanding of pyasn1 (or both:-)

I think that dealing with the two points above would be a major improvement for pyasn1 and make its future more sustainable, because it would codify the knowledge into text, rather than keep it in the heads of the few experts out there.

The troubleshooting guide could explain:

  1. How to read and interpret the error message?
  2. What rules of thumb can help narrow down the set of hypotheses and find the root cause?

The error message itself could benefit from:

  1. Indentation
  2. Indication of where in the structure we are at the moment of the error. For example, if named types are used, the problematic name could be listed in a prominent part of the error message.
@lextm
Copy link
lextm commented Feb 7, 2024 •
edited
Loading

While this is a very good proposal, I wonder if it can be done in a single step.

The original author passed away and the current maintainers seem to have difficulty fully taking over (like the troublesome 0.5.0 release indicated).

I think more practically people might start to work on a few case studies (either new issues or old ones from the original repo) and share the thorough analysis reports publicly for others to review.

Readers can immediately learn from those reports as they show the common approaches needed. Once the reports are there, we might be able to compile a more general guide for the audience.

@ralienpp
Copy link
Author

What would be an appropriate format for collecting this information? For example, I recently had an issue which I couldn't resolve; with some assistance from Russ Housley I got a working version - his code is somewhat different, though in essence it looks similar (e.g. using x['test'] instead of x.getComponentByName('test'), and other quirks of this kind). He can empirically find a working way, but an underlying explanation of why it is the way it is - is not available.

Perhaps we could open the discussion section of this repo and provide such pairs of examples, and give them a specific tag? Or create issues with a particular tag?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ralienpp @lextm
0