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

Remove error() and re-inspect assert() calls. #8506

Closed
3 tasks done
yurydelendik opened this issue Jun 9, 2017 · 5 comments
Closed
3 tasks done

Remove error() and re-inspect assert() calls. #8506

yurydelendik opened this issue Jun 9, 2017 · 5 comments
Labels

Comments

@yurydelendik
Copy link
Contributor

yurydelendik commented Jun 9, 2017

There is lots of confusion how error() is used. It also may mislead people when reading source code -- error() hides throw new Error(), so it's not easy to see control flow for human and JS analyzers cannot complain about dead code.

The same issue can be found with assert(). Normally assert() is used to define precondition for the following code, means that code shall never have its check false. (In other languages it's usually defined as hard stop for the program). By hiding checks and throw inside assert(), we also potentially removing JIT ability to make some assumptions.

  • Introduce InvalidPDFError() to raise when PDF is malformed instead of generic Error()
  • We need to review code and change error(_) => throw new Error(_)
  • We need to review code and change assert(_,?) => if (!_) throw new Error(_) for non-assert-like calls (test for it is: it's impossible to remove this check/assert without changing logic of the program and affect the testing)
@brendandahl
Copy link
Contributor

We need to review code and change assert(_,?)

Just to clarify on this one, do you mean keep assert() for proper uses, but change other assert's to throw?

@yurydelendik
Copy link
Contributor Author

Just to clarify on this one, do you mean keep assert() for proper uses, but change other assert's to throw?

Correct. We will keep assert() for proper uses.

Also since we cannot just simply abort the app, let's keep throwing inside assert() for now. However it will be nice to see process.exit(1), worker.terminate() or at least while(1); :)

@Snuffleupagus
Copy link
Collaborator

Snuffleupagus commented Jun 9, 2017

Introduce InvalidPDFError() to raise when PDF is malformed instead of generic Error()

We already have a similarly named InvalidPDFException, defined in src/shared/util.js#L425, which is currently thrown if we're unable to recover a valid XRef table; please see src/core/obj.js#L1130.

There is lots of confusion how error() is used.

Unless your intention is to reuse the existing InvalidPDFException, we probably ought use a name that's not too similar to avoid real confusion here :-P

@yurydelendik
Copy link
Contributor Author

We already have a similarly named InvalidPDFException

InvalidPDFException wfm

@yurydelendik
Copy link
Contributor Author

yurydelendik commented Jun 29, 2017

adding unreachable(msg), which is just a shortcut for assert(false, msg)

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

No branches or pull requests

3 participants