-
Notifications
You must be signed in to change notification settings - Fork 10.2k
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
Comments
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 |
We already have a similarly named
Unless your intention is to reuse the existing |
InvalidPDFException wfm |
adding |
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.error(_)
=>throw new Error(_)
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)The text was updated successfully, but these errors were encountered: