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.

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

Error-handling somewhat awkward #29

Open
davidben opened this issue Nov 27, 2012 · 0 comments
Open

Error-handling somewhat awkward #29

davidben opened this issue Nov 27, 2012 · 0 comments

Comments

@davidben
Copy link
Owner

I wonder if we can do a little better here. JS already provides an Error class. The context constants probably ought to be classes (er, prototypes). Also might be good to distinguish user-level errors from internal ones. For instance, ReferenceError is probably better left uncaught. Also any ASN.1-level errors. Debug tools can then catch it and we go from there.

We can have an error type per component, and the ui.js top-level handler can whitelist a few to report to the user and re-raise the rest (reporting "oops, something broke").
davidben added a commit that referenced this issue Nov 28, 2012
@davidben
Throw non-string exceptions in asn1.js
b62f434 
Issue #29. Dunno how useful this'll be. I'm thinking asn1.Error could be
errors in asn1 encode/decode, but we'll use things like TypeError to
deal with internal errors. Arguably all those can just throw strings for
random internal errors. Those are internal errors that we probably don't
never need to show to the user. Mainly we just want that exception to
propogate to top-level.
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
1 participant
@davidben