Details
-
Bug
-
Resolution: Fixed
-
P4
-
None
-
None
-
b82
Description
the various error throwing methods aren't detectable as control flow endpoint by the ide.
For example typeError throws a type error (runtime exception < ECMAException), but our IDEs don't know that. It is much nicer if we let the various error throwing methods return the error to be thrown instead, and throw it explicitly from code. For example
if (types == null) {
typeError("...");
}
use(types)
will warn that types can be null at the "use" line, which it can't. It would be better if it looked like:
if (types == null) {
throw typeError("...");
)
use(types)
and is also much easier for a person unfamiliar with the code to understand when reading the code. It is not apparent that "typeError" indeed breaks the control flow
For example typeError throws a type error (runtime exception < ECMAException), but our IDEs don't know that. It is much nicer if we let the various error throwing methods return the error to be thrown instead, and throw it explicitly from code. For example
if (types == null) {
typeError("...");
}
use(types)
will warn that types can be null at the "use" line, which it can't. It would be better if it looked like:
if (types == null) {
throw typeError("...");
)
use(types)
and is also much easier for a person unfamiliar with the code to understand when reading the code. It is not apparent that "typeError" indeed breaks the control flow