So like in any programming language, we can make syntax errors. And it's a little different, and so you'll notice that one of the things I have had to bug you about in every programming language. Like in PHP you had to set the error display message in the php.ini file, you had to set the error mode on your PDO so that you would see the errors. The problem with having errors, is you've gotta see them as a developer. And so JavaScript is kind of weird, in that it runs in the browser as a sort of a side effect of loading a web page. And the person looking at the browser is usually not the developer. And so the default is that the browsers just hide all of the errors. Sometimes they'll put a little red mark in the lower right hand corner or something, or a question mark or something, but you don't see it. And the reason is, is the person who is standing looking at the browser is not likely the person who wrote the code in the first place. And they're probably not a programmer, they're the end user of your application. And so what happens is, it detects an error and it stops the script execution, but it doesn't notify you. There's no error log like we have in PHP, etc, etc. So it's important to know how, when you're writing software and doing development, how you can catch and notice errors. because you're going to make mistakes as you're developing JavaScript. So this is an example of some broken JavaScript code. So we have two script tags, two script tags. And this script tag has a mistake, it has a single quote ending a double quote. Single quotes and double quotes are equivalent in JavaScript, which is actually quite nice, and so that's a broken tag. And so what happens is, is that it comes in here, and it starts this script. And it's running it, but this is a syntax error so it doesn't run, and it blows up. And what it does, is it doesn't run any of the remaining script codes. So it never says, I am good. It basically gets out of that script block, so that's what happens. And there's trys, and excepts, and things like that in JavaScript, and we can talk about that. But in this case, we don't have a try or an except, and so it just stops that block. So this is one block of JavaScript, this is another JavaScript. What it doesn't do, is it doesn't stop all JavaScript processing, it just sort of blows up this block, okay? And so even though it comes down here and gets to paragraph two, then this runs. And this is good JavaScript, and it runs. And so that's why we see this alert, Second time, is that hope springs eternal in JavaScript. And when it sees a new script tag, it's like, well, I'll run this. But it doesn't bother, as soon as it sees a single error, it doesn't go any further. And sometimes this is library code, and it's defining functions and stuff. And you make a syntax error, and then all the rest of the functions in the file don't exist. So you have to realize that a single error in a JavaScript, either a JavaScript file, or between a script and end script tag, one error sort of throws everything after that error away. You gotta get used to that, it doesn't run any more after that. But we have to see the error, and like I said, the end user is the one looking at the browser. And so we need to be able to say hey, where's this error at? And so we need to make it so that programmers can see errors, but users are not sort of, they're not thrown in the user's face. Now the user notices that your application stops working, but maybe it's not critical, or something like that. And so we, as developers though, we want to see it, so we always have to turn something on. What's super convenient these days, thankfully, is that the browsers have a debugger mode in it, a developer mode in it, that shows you this stuff. And so you can see the errors by going into the developer mode. Now sometimes you gotta go, how to enable developer mode on Chrome, or how to enable developer mode on Firefox. because sometimes they don't even put the menus up for how to do developer mode. So that's the first thing you gotta figure out, is how to get to developer mode. But once you get into developer mode, you basically get a split screen, and you can actually pull this out and make it on two screens, or whatever. And there's a lot of ways that you can show this, I think this little thing moves it out. But under Console, you can see all the error messages, and you see the fact that there is an error message. So some developers will actually make this the bottom part, so you have a screen and the bottom part, they just leave the Console all the time. And sometimes I'm running other people's code, and I just watch the Console for a little kind of Easter eggs. One time I saw a Console where a company was asking you to apply for a job. So that if you're going to their website and you happen to be watching the Console, it would go like, hey, apply for a job. because you can actually send log messages, which we'll soon see, out to this Console. Now it's usually pretty effective, and sometimes you have to refresh the page. But if it sort of knows that you're in developer mode and it finds something, you can click on this actual link, and it takes you right in the source code. So you do not have to go View Source, fool around. It knows all the source code, it knows what line you're in. Now some of these things look really ugly. There's this little thing that if you end up with this, what's called minified JavaScript, it's all one big long line with rat crappy stuff. You can actually make it pretty so you can read it. But this is taking you right to line three of the exact code that was broken, telling you what's wrong. You can kind of hover over it, Uncaught SyntaxError, so that's how you debug it. And so you'll find, increasingly, as you're writing JavaScript, you'll just have this split screen on all the time. And you'll do things like clear the logs, hit the refresh button, and see what errors you've got. And now you're debugging your JavaScript, and you're using the browser to do it. And the fact that there's a debugger right in the browser is one of the reasons people kind of think that JavaScript is a good first programming language. But this whole thing is actually monstrously complex for absolute beginning users, and I think it's cognitive overload. But enough of me talking about whether or not, I love Python as the first programming language. And then PHP, and then SQL, and now JavaScript, because JavaScript is an awesome language. I talked about the alert message, but the alert message is really not very practical because it stops everything. I use alert when nothing make sense, and I'm like, I'm sticking an alert in here. I've just got to stop right now, because sometimes I don't know what order things are happening in, and so an alert would be stop. And it's not like it goes flying somewhere else, you can see okay, this alert is happening right here. But a far more useful thing to do is console.log. And console.log, you can kind of look up all the different functions of console, but console.log basically puts a string. You can also log variables, and see the contents of those variables, and it's really quite nice. And so you can see the console log, is these are messages that you're putting out, right? And if you look at this one, you'll see that the first log appears, then the dialog box stops. The second one does not happen because the dialog is suspended, and away you go. But the nice thing about this, and I actually, in production systems that you'll use, and mine, you will sometimes see log messages coming out. Because I'll be debugging, I'll say the iframe didn't resize. And I'm like pop up the developer console and look in the log, and I'm like why is that? What's that red error message? Screenshot that for me, and show it to me. And so I will leave stuff in my running applications sometimes. Nothing that's revealing secure information. Of course, nothing that JavaScript does is really secure, because like cookies it's in the browser, so the user can look at it. And a smart user can watch the JavaScript running, can look at the JavaScript, can change the JavaScript. So you can't trust the JavaScript, even if you wrote it. The thing that's running in the browser may or may not be your code. Okay, so in older browsers, sometimes the console was only there if the debugger was running. I don't know which browsers did it, and I don't know what versions of browsers did it. But if I'm leaving stuff in production, I will tend to say this. So window.console will retrieve true or false without blowing up, and then && console.log. And so if this is false, then this doesn't run, and if this is true, this does run. And it's a way to avoid getting a syntax error inside of the debugging statement. Another way to do this, and you can sort of ask in Stack Overflow, what about console? Is console always there? And there's a whole bunch of other things. And so this is really for older browsers, but I'm still a little conservative in my applications that I write. You probably won't bother. You'll just say console.log, and you'll run in Chrome, and it'll just be fine, and so you'll be okay. There is a debugger. If you get into a source view, you can find your way into source view, and you can click on a line of JavaScript to set the breakpoint. Sometimes you sort of have to be in source view and hit refresh one time. Or if you hit the breakpoint then you had to hit refresh, unless you're in the pause debugger, because the page is already done. You hit refresh, the page is done, and you're looking at this line of code, well that code executed a while ago. Then you can set a breakpoint, and then refresh, and the next request response cycle is when you're going to see it. So sometimes to activate the debugger, you have to refresh the page after you set a breakpoint. And so at some point, you're sort of finding your way around in some source code, you find the code, and then you hit the button. And this little flag, this little blue flag shows up to say that you are in the debugger, that you have set a breakpoint. Then you hit refresh, and then it knows, it remembers, and it says I'll stop here. So now what it's basically saying, is it's stopped right here in the debugger, and then you press this to continue. But you can look around at variables and other kinds of things. And that's really quite nice, but I'm always having trouble finding my way around. So I don't think it's really great for beginners, but once you get good at it, it's a really powerful, powerful environment to figure out what's going wrong with your JavaScript. So up next, we're going to talk about JavaScript kind of as a programming language.
