Transcript from the "Statements" Lesson
>> 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: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: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.
>> 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: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.
>> 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?
>> 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.