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

Improved error handling #1

Open
rmhrisk opened this issue May 2, 2014 · 5 comments
Open

Improved error handling #1

rmhrisk opened this issue May 2, 2014 · 5 comments
Assignees

Comments

@rmhrisk
Copy link
Contributor

rmhrisk commented May 2, 2014

It would be good to see improved error handling so that programatic handling and debugging of encoding problems can be handled better.

@felix
Copy link

felix commented Jun 2, 2015

For instance, the error returned at org/pkijs/asn.js:4795 gives no indication of errors buried deep in the schema but instead returns simply (and quite possibly incorrectly) 'Wrong values for choice type'.

@YuryStrozhevsky
Copy link
Contributor

Yes, the error hadnling is still not good in ASN1js. But the error you mentioned is a real error (and it is correct error, 100%). The error you got when in schema and in data you have different values in CHOICE type. For instance when in schema you have ASN1_CONSTRUCTED but in data you have ASN1_PRIMITIVE.

@felix
Copy link

felix commented Jun 2, 2015

If the schema fails to verify below a CHOICE type then the error only mentions the invalid choice type when in fact the error could be buried deeper. This is due to the recursive compareSchema function called on each of the choices.

@YuryStrozhevsky
Copy link
Contributor

Sure, and you can verify "error" field of nested types in order to find out an "initial object with error". If you have any proposals/recommendations about error handling feel free to say me about them.

@JanFellner
Copy link

JanFellner commented Nov 10, 2022

As i have seen this ticket i wanted to bump in the solution we made on our fork of the library.

https://github.com/ESTOS/ASN1.js

The different validation issues are now enum value based (no longer text based)
The validation carries a context while it parses and thus exposes where in a hierarchical structure an error has occured (NAME:SUBNAME:SUBSUBNAME, if no name is provided the tagclass-tagname is used instead)
The errors are now an array and thus may contain mulitple errors

The behaviour of the validation is configurable with VerifyOptions (continueOnError allowLargerThanSchema)

Existing test succeeded, added a bunch of new test for optionals, choices and schema validation in general.

(Have no expectation that this is getting merged as the changes are quite large but maybe someone hops in and needs a solution and may be a good start to additional improve diagnsotics)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants