Throw a type error when a non-object is called

[joshwd36]

This Pull Request fixes #510.

Previously if a value other than an object was called as a function undefined would be returned. Now throws a type error.

[codecov]

Codecov Report

Merging #561 into master will increase coverage by 1.10%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #561      +/-   ##
==========================================
+ Coverage   68.19%   69.30%   +1.10%     
==========================================
  Files         172      172              
  Lines       10573    10580       +7     
==========================================
+ Hits         7210     7332     +122     
+ Misses       3363     3248     -115     

Impacted Files	Coverage Δ
boa/src/exec/mod.rs	70.44% <100.00%> (+1.71%)	⬆️
boa/src/exec/tests.rs	100.00% <100.00%> (ø)
boa/src/syntax/lexer/mod.rs	56.09% <0.00%> (+0.24%)	⬆️
boa/src/builtins/number/mod.rs	65.62% <0.00%> (+0.44%)	⬆️
boa/src/builtins/object/internal_methods.rs	30.36% <0.00%> (+0.52%)	⬆️
boa/src/builtins/function/mod.rs	69.42% <0.00%> (+0.63%)	⬆️
boa/src/environment/lexical_environment.rs	75.72% <0.00%> (+0.97%)	⬆️
boa/src/syntax/ast/punctuator.rs	2.12% <0.00%> (+1.06%)	⬆️
.../src/environment/declarative_environment_record.rs	38.66% <0.00%> (+1.33%)	⬆️
... and 33 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6a721f9...7fe6921. Read the comment docs.

[HalidOdat]

Looks good! could we have a test for this, maybe something like:

let x = false;
try {
	undefined();
} catch(e) {
	x = true;
}

and we assert that x == true

[joshwd36]

Looks good! could we have a test for this, maybe something like:

let x = false;
try {
	undefined();
} catch(e) {
	x = true;
}

and we assert that x == true

Yes, I'll do that. I was wondering what the best way to test exceptions would be.

[croraf]

Looks good! could we have a test for this, maybe something like:

let x = false;
try {
	undefined();
} catch(e) {
	x = true;
}

and we assert that x == true

Yes, I'll do that. I was wondering what the best way to test exceptions would be.

I don't like this. I've been thinking about that when I had the same "how to test the exception issue. I concluded that it is much better to do the following:

try {
	//expression that throws the error here;
} catch(e) {
	e.message;
}

and then assert that the output of this script is the correct string (the error message).

[joshwd36]

That's a good point, and is actually what I ended up doing with the tests as I saw that had been used in the tests file already.

[croraf]

Oh, cool. I see now.

I was thinking before how to add the subject ("what" is not a function) to the message, like Chrome mentions this subject ({}.func) here:

But to me this seamed as a difficult task, as the subject on which the Call is invoked can be a wide variety of things:

(some_complex_and_long_expression_that_returns_a_function)()

and Chrome has some way on printing that out in a short form.

Would be worth to explore how to do this, perhaps as a separate Issue. What do you think? (Perhaps it turns out it is not that difficult as I think.)

[HalidOdat]

try {
	//expression that throws the error here;
} catch(e) {
	e.message;
}

This gives us msg

Yes. this this is a step in the right direction, but we still aren't testing what type of error it is, which is the most important part of testing, I think we can improve this by:

try {
	//expression that throws the error here;
} catch(e) {
	e.toString();
}

This gives use TypeError: msg

What do you think?

But to me this seamed as a difficult task, as the subject on which the Call is invoked can be a wide variety of things:

(some_complex_and_long_expression_that_returns_a_function)()

and Chrome has some way on printing that out in a short form.

Would be worth to explore how to do this, perhaps as a separate Issue. What do you think? (Perhaps it turns out it is not that difficult as I think.)

Maybe this could be done by keeping a span of the source code for function call node and when we error we concat the source span and the message description is not a function to get someExpression is not a function.

[joshwd36]

try {
	//expression that throws the error here;
} catch(e) {
	e.message;
}

This gives us msg

Yes. this this is a step in the right direction, but we still aren't testing what type of error it is, which is the most important part of testing, I think we can improve this by:

try {
	//expression that throws the error here;
} catch(e) {
	e.toString();
}

This gives use TypeError: msg

What do you think?

That's a good point. I'll make a seperate PR for that because there are already a few tests that use the previous method, and this one has already been merged.