Statements

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Douglas Crockford: We have the same set of statements that you would expect to see in a C language, again with some differences.
>> Douglas Crockford: We've got labeled break, which is good. So if you've got nested loops and switches and stuff, you can break out of innermost things, which is good.

[00:00:22]
We've got the for statement which we can use to iterate through arrays but I don't recommend using that. In ES5 we got the forEach method, the map method where you can have a function called on each element of the array. That eliminates almost all need for the for loops, so I don't use for loops anymore.

[00:00:42]
We have a for in statement which iterates through all of the names of all the properties of an object. Unfortunately it also iterates through all of the inherited properties which is usually your methods and so your methods get mixed up with your data and it gets to be a mess.

[00:00:57]
Fortunately we got, in ES5 we got Object.keys which takes an object and returns an array of strings which is just the enumerable own properties of the object which are usually the ones you want. So I don't recommend using for in either. We already talked about the problems with the switch statement.

[00:01:19]
One thing about the switch statement though. JavaScript improved the switch statement in one way and that is that the switch value does not need to be a number. It can be a string which can be very nice cuz you can switch on a greater set of values. And the case values can be expressions, they don't have to be constants.

[00:01:39]
So that can be useful in doing internationalized applications that you can case against a function which will return the yes value for this language. It could be a nice thing,
>> Douglas Crockford: We have exception handling in this language which is nice. Before ES3 we didn't, which meant that you had to write programs that never went wrong ever because there is no way to recover from anything, that was hard, so we got exceptions now.

[00:02:12]
You can throw literally any value. There's a convention that you throw something that comes from a new constructor, which is the same as creating an object that has a name property, and a message property. But in fact, you can throw literally anything. So the way that exceptions are used is very different than in Java.

[00:02:35]
And so exception handling is very simple because we don't have exception types. There's only one catch block, and it catches everything. And generally, it's going to ignore whatever it caught. It doesn't care what happened. All it knows is or all it cares about is that didn't work, so let's try something else.

[00:02:52]
Maybe it'll work instead. So in Java you tend to see exceptions used to implement a form of computer go to, where you can get very complicated control paths that are dictated by whoever threw the exception. And I think that was probably a big mistake. JavaScript didn't make that particular mistake.

[00:03:10]
So we tend to use exceptions properly. Use them only for failures. We'd never do normal control paths using exceptions.
>> Speaker 2: Sorry.
>> Douglas Crockford: Yeah.
>> Speaker 2: Could you clarify that? I didn't understand that statement.
>> Douglas Crockford: So in Java there's a tendency to look at why did this fail, right.
>> Speaker 2: Different reasons, different catch, try exception A, exception B, exception C.

[00:03:40]
>> Douglas Crockford: Yeah, exactly. It got a whole exception cases, and so you’ve got who threw the exception, deciding how you're gonna go through your code and that usually means that the exceptions are not actually exceptional. They're just alternate control paths, right? And sometimes it's motivated by weakness in the type system that you've got something that wants to return an int but something else is gonna happen which is not exceptional, it's just not an int.

[00:04:11]
[SOUND] I'm out of values and so you'll throw exception instead. Whereas in JavaScript because we're loosely typed you can pass a number or you can pass undefined or you can pass a string, or you can pass an object, you can return anything that you need to. And so these things are not exceptions.

[00:04:30]
They're just more modes of normal processing. So your control flows tend to get much simpler. Any other questions? Okay, so that's the end of this hour. So let's take a break and we'll come back.
>> Speaker 3: Hey I have a quick question from chat. People were asking why you don't use for loops and instead favor for each.

[00:04:54]
>> Douglas Crockford: Yeah. For each is just much nicer. Once you get used to it, it's more readable. In future versions of the language it's going to be paralyzable. It's a more modern construct. It's more functional. It's more composable. It's better in every aspect.
>> Speaker 3: What about the fact that you can't leave a for each with a return?

[00:05:22]
>> Douglas Crockford: I'm sorry?
>> Speaker 3: The fact that you can't leave a for each, like stop a for each loop.
>> Douglas Crockford: You can, you can instead of using for each use every, and then you can have something return false and then it stops.